We can do it right, fast, or cheap
Pick any two
It’s a great way to shirk responsibility now, for future problems later.
What do we mean by right, fast, or cheap? In the context of software development:
- Doing it right means maintaining a clean, well-structured, and well-designed codebase
- Doing it fast means we get tangible results quickly
- Doing it cheap means we don’t spend much time or money on it
As John Venn would say: A picture speaks a thousand words.*
The suggestion here is that there are mutually exclusive properties involved in software development.
That is:
- By virtue of trying to do something “fast & cheap” means sacrificing quality.
- Alternatively, doing things “right and fast” would be expensive in person-power & monetary cost.
- Lastly, doing things the right way at reduced cost would take a long time.
As a junior and middling software developer, I spent years living to this mantra. It was an easy way to pass the buck in software development. When asked “How long would ‘X feature’ take to implement?” my responsive would invariably be “Depends. We can do it right, fast, or cheap; pick any two.” And inevitably, we would select fast & cheap.
Problem is, it’s completely wrong.
Over the years I have since grown to realise that this notion is a fallacy. Perpetuating this mindset can lead to a dangerous situation for any software development team: A low-quality product.
A policy of “Quality - If Time Permits” will assure that no quality at all sneaks into the product. (1)
What is ‘Quality’?
I see there being two types of quality when it comes to describing software – Functional & Non-functional
Functional: Is the product built to specification? Quality products adhere to clearly defined requirements. Simple as that. But how do we cater for the types of requirements that affect those building the software, rather than those using the software?
That’s where non-functional requirements come into play.
Non-functional: Can be characterised by asking questions like:
- Can new features be easily implemented?
- Do changes to the codebase introduce bugs elsewhere?
- Is it well-documented?
- Can it be easily tested?
- Can it be easily deployed?
Here, the recipients of software quality are the people involved in building the software. These considerations are important as they play a huge role in the speed with which a team can deliver software.
Workers kept under extreme time pressure will begin to sacrifice quality. They will push problems under the rug to be dealt with later or foisted off onto the product’s end user. (1)
The harder it is to work with a codebase, the more likely it is that corners will be cut to get the job done. Tight timelines, over-promised delivery dates and a constant need to produce output? These all contribute towards a mindset where the best solution is abandoned in favour of just shipping it out the door.
What follows then is an accumulation of short-cuts, quick-fixes and kludges. Otherwise known as technical debt.
Codebase quality plays a direct part in the amount of time spent bug-fixing, as opposed to delivering new features. It’s not uncommon to be playing a game of whack-a-mole where a new feature or bug-fix introduces a different issue elsewhere in the system.
All of this takes time, and that time is better spent delivering value. When all these obstructions are removed from our path, we produce software faster.
Here’s an idea: What if we redefine the notion that quality is an enabler of faster delivery? That by doing things right to begin with, we are setting ourselves up for long-term success. We’re now able to deliver new features and updates faster than we could if we had a mountain of technical debt blocking our path.
Quality, far beyond that required by the end user, is a means to higher productivity. (1)
Earlier, I introduced the notion of “Right, Fast or Cheap” as an interaction of mutually exclusive properties. Let’s redefine this interaction as something that amplifies our outcome, instead of compromising our outcome.
Suppose that, doing it right makes it fast, which by extension makes it cheap.
This concept is not new. In fact, it was recognised decades ago and published in an article titled Inside the Japanese Software Industry.
The trade-off between price and quality does not exist in Japan. Rather, the idea that high quality brings on cost reduction is widely accepted. (2)
Let’s add some specificity to this notion by re-naming these concepts.
In clearer terms:
- Fast: Let’s call this “Productivity” (P)
- Right: This can equate to “Quality” (Q)
- Cheap: Define this as “Value” (V)
Therefore:
\[V=f(Pf(Q))\]That is to say, the value output of a team (or product, or project) is a function of productivity, which in turn is a function of quality. As quality improves, so too does productivity, which increases the value of the deliverable.
It’s all very well to hand-wave at some colourful diagrams and fancy pseudo-mathematics, but how can we make this actionable?
What steps can we take as participants in the software development lifecycle to achieve faster delivery times through high-quality practices?
Good question, and an excellent topic for a future post!
References:
-
Zec, Joe (March 2002). “Peopleware: Productive Projects and Teams”. Software Quality Professional. American Society for Quality. 4 (2). ISSN 1522-0540.
-
T. Matsubara and D. Tajima, “Inside the Japanese Software Industry” in Computer, vol. 17, no. 03, pp. 34-43, 1984. doi: 10.1109/MC.1984.1659080 Abstract: https://doi.ieeecomputersociety.org/10.1109/MC.1984.1659080