Don’t plan for 101 Variations

Somewhere between the famous Henry Ford quote of “Any customer can have a car painted any color that he wants so long as it is black” and near infinite clothing options of the video game world lies the reality of most finished⁽¹⁾ software projects; half a dozen main variants with three to four sub variants, some of which are mutually exclusive.

However, one common mistake in the software development process is a tendency to plan for all outcomes or in other words, have 101⁽²⁾ variants.

How do we get here?

The proliferation of variants happens under two basic scenarios; “scope creep” and a failure to define requirements up front.⁽³⁾ In either of these cases engineers start creating “what if” scenarios. “What if the car needs to drive faster than 90 mph?”; “What if the XXX?” “What if my refrigerator needs to run on Mars?”⁽⁴⁾

Each of these scenarios is “possible” and for the most part come from engineers trying to ensure that the resulting code is robust but it also comes from a lack of leadership.

Hold on to your requirements

This is where requirements traceability shines. If engineers as they work have a clear definition of what they need to be working on, and that definition is always present than the outcome is predictable.

What happens when you let go?

Adding additional variants adds costs in 3 ways

Additional testing required: Not only does the additional variant need testing in a stand alone mode, but it needs to be tested in an integrated system.
Adding complexity to interfaces: Unique variants often require unique interfaces. The more interfaces that are added the more likely that there will be integration issues
Speed!: Each additional variant adds in overhead for each step of the development process, from testing to code generation.

Footnotes

“Finished” with software can be a problematic concept; there can always be patches and updates. For the purpose of this article, finished refers to the first shipment of the product.
When I write “101” here I am not saying “0b101”.
Often “scope creep” occurs when there are poorly defined requirements, but it can also happen when the requirements are not well understood or enforced.
These questions are in decreasing order of possible variants, unless you work for NASA then it is something you should consider.