Last month, I was visiting a friend’s repair shop, and noticed this ‘Service Policy’ posted on his door, somewhat as a joke:
We provide service which is CHEAP, FAST & PERFECT
You can have any two
If you want it Cheap and Fast, it won’t be Perfect
If you want it Cheap and Perfect, it won’t be Fast
If you want it Fast and Perfect, it won’t be Cheap
According to the American Heritage Dictionary, a Trichotomy is:
- Division into three parts or elements.
- A system based on three parts or elements,
especially the theological description of humans as consisting of body, soul,
and spirit.
It seems to me that the sentiment expressed by the Service Policy fits this definition. There are 3 parameters that have to be combined in the right mix to provide a product or service. We also see this trichotomy in software development. The 3 parameters are usually: Delivery Date, Number of Features, and Quality. For software development, the trichotomy is usually expressed like this:
Features, Date, or Quality: Pick any two!
More completely, this simple phrase is expressing the nature of software development like this:
- If you want a large set of New Features and high Quality, then the Delivery Date can’t be pre-determined.
- If you want a high Quality and a pre-set Delivery Date, then you won’t have all of the large set of New Features you can imagine.
- If you want a large set of New Features and a pre-set Delivery Date, then the software Quality will be suspect.
Isn’t it interesting that some management teams will always want to define all three parameters, and refuse to admit that setting the first 2 will always cause a compromise on the 3rd parameter? Over my years in the software industry, I have been 1st hand witness to several product releases where the mix was just right (SQL Anywhere versions 11, 12 and 16 come to mind). Unfortunately, I have also witnessed a couple of situations where the mix was wrong, and one of the 3 parameters was seriously compromised. Sometimes the quality aspect suffers, and sometimes the date slips.
While it pains me to admit it, in the early days of SQL Anywhere, we had a release where the Delivery Date and the large set of New Features caused the released Quality of the software to be suspect. Let me tell you, shortly after release, we certainly heard about it from our customers! After that experience, we have always made sure that high Quality was the first parameter defined. Over the years, we have greatly expanded our testing processes and systems. Today, we refuse to ship if there are ANY priority 1 bugs in the software.
Some of our customers will also remember our version 10 release, where we again defined a large set of new features, but having learned the lessons from the past, we refused to compromise on Quality. As a result the Delivery Date slipped several times.
When you are planning your next development project, consider how you will mix the 3 essential aspects of software: feature set, quality and delivery time. It is important to understand what will be compromised if you define 2 of them.
