Killing Software Projects with Modal Verbs

Tuesday, October 2, 2007

Modal verbs are the words that express a degree of certainty, like: may, can, will, shall, must. You see them in RFCs all the time:

1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification.

In the old days, software analysts would descend from mountain peaks with reams and reams of software requirements arranged in three-ringed binders. These requirements also came with words like "must" and "may". After a couple months, developers would repurpose the binders as doorstops and monitor risers. 

The days of thick binders are over, thank goodness, and the days of more frequent face-to-face communications are here. The communication has to be obvious and lucid in order to work, however. Analysts were good at using the "proper" language to shape results. The same decisiveness has to come across in today's whiteboard and water cooler discussions.

What the tech lead says: You may want to possibly refactor that class.

What the junior developer hears: The code is gold!

I've been in conversations where the words "may", "maybe", "perhaps", and "might" dominate the discussion. These discussions are never productive, and make a leader or expert appear indecisive and unconfident.

From Hacknot:

A Technical Lead lacking in self-confidence can be a major frustration to their team. They may find themselves waiting on the Lead to make decisions that significantly effect their work, but find that there is some reticence or unwillingness to make a firm decision. Particularly when new in the role, some Technical Leads find it difficult to make decisions in a timely manner, for they are paralyzed by the fear of making that decision incorrectly. Troubled that a bad decision will make them look foolish, they vacillate endlessly between the alternatives, while their team mates are standing by wondering when they are going to be able to move forward.

You could substitute "domain expert", "product manager", or "stakeholder" for "technical lead" and the paragraph still makes sense. Many times the problem isn't timely decision making but ineffective communication. Maybe that's just the individual's personality. Perhaps they are just being politically correct or may be timid.

What the stakeholder says: The last change we might want to possibly make is to change this screen to maybe make the buttons stand out a little more.

What the developers hear: We are done! Ship party!

It's perfectly fine to be an expert and say "I don't know", or "this requires some research", but when possible you need to paint the world in shades of black and white to keep a team moving towards the goal.

You must make decisions.

You must clearly communicate those decisions.


Comments
Jason Meridth Tuesday, October 2, 2007
Excellent post. We have a lead who is very polite but sometimes has issues be declarative. This is an excellent example of that and is a good read for him to express how people underneath him feel.

Thanks.
Filini Wednesday, October 3, 2007
The lack of decision taking by the Technical Lead / Business Analyst Division leads to an interesting work flow (the one I'm currently using where I work):

1. The Analysts decide we should implement some kind of feature
2. We ask some details on the feature
3. Knowing perfectly that they won't take decisions, we start developing the new feature as we like it
4. We finish the new feature development
5. By this time, they usually tell us "Hmmm we don't know the best solution for this feature... maybe this behavior should be in the configuration file... or maybe not..."
6. We document our feature (already implemented), and this becomes the Software Requirements

You may not believe me, but this flow works extremely well - from the developers point of view :D
Comments are now closed.
by K. Scott Allen K.Scott Allen
My Pluralsight Courses
The Podcast!