In the classic movie The Princess Bride, one of the villains is repeatedly and consistently surprised by the skill and competence of the story’s hero. Vizzini’s constant cry each time of “inconceivable” drives Inigo Montoya to say “You keep using that word, I do not think it means what you think it means.”

Part of the reason this is so funny (seriously, you should see the movie if you haven’t already) is that we see this kind of language misuse all the time in the real world. Unfortunately, we seem to be particularly prone to this particular habit in the word of software development.

I once worked within a team where the word mandatory was (mis)used to indicate that a particular feature was considered a high priority for the next release of the software. The business analyst on that team used this as a kind of power play, trying to force features into the next release regardless of the consequences (and, sometimes, regardless of the wishes of the business unit).

Labelling a feature mandatory gives absolutely no room for negotiation, no wiggle room at all; the feature must be present for the delivery of the system to be accepted. To some (including the business analyst I mentioned above) see this as a powerful lever to get their own way. Unfortunately, they do this while ignoring the other consequences of the label. Any proposed release that lacks a mandatory feature must be rejected outright.

In other words, if you decide that a feature must be present for a release to be accepted, any release without that feature must be rejected.

While some software features are undoubtedly mandatory, most features described as such are merely very important. Very few proposed features are actually mandatory.

For example, it’s mandatory for an online email system to show me only the email I’m supposed to see; if I could log into my email and see someone else’s messages - or if they could see mine - that would be a fatal flaw. If a tester saw that behaviour during testing of a release, that would easily be justification for rejecting the release outright.

On the other hand, consider a feature to automatically translate an email message into the native tongue of the user, helping people to communicate across language boundaries. While this might be immensely desirable, perhaps even strategically important, it shouldn’t be described as mandatory because failure to deliver isn’t serious enough to close down the system.

Let’s commit to using the correct vocabulary in our work - reserving the word mandatory for those times where failure to deliver means failure of the project - turning everything off and walking away.


blog comments powered by Disqus
Next Post
What's the value of a passing unit test?  02 Apr 2017
Prior Post
Why Immutable Types?  11 Mar 2017
Related Posts
Browsers and WSL  31 Mar 2024
Factory methods and functions  05 Mar 2023
Using Constructors  27 Feb 2023
An Inconvenient API  18 Feb 2023
Method Archetypes  11 Sep 2022
A bash puzzle, solved  02 Jul 2022
A bash puzzle  25 Jun 2022
Improve your troubleshooting by aggregating errors  11 Jun 2022
Improve your troubleshooting by wrapping errors  28 May 2022
Keep your promises  14 May 2022
March 2017