In a perfect world, when building a product, one would develop it within budget, deliver it on time, and meet the highest degree of quality. The problem is that we do not live in a perfect world. In reality we are faced with situations that require us to make trade offs and sacrifices between time, quality and cost.
Based on what I’ve observed throughout the years, when it comes to making these sorts of tradeoffs, the convention is that quality should always be sacrificed first. The reason for this is simple, there is always a race against cost and time. In other words, cost and time have limits that are closely tracked against a budget and a schedule respectively. On the other hand, there is hardly ever a race for quality. This is mostly because quality does not have a clear limit and it’s not as easy to track, which means that it can be postponed.
This should not come as a surprise. After all, one of the most famous mantras of Silicon Valley has been “move fast and break things”. I won’t argue that such an approach is oftentimes necessary and works very well in certain circumstances (specially when you need to grow fast no matter what). But it is definitely an approach that comes with a usually undermined cost that ironically makes it more complicated and expensive to move fast and break things as one scales. Therefore, in the following sections I’ll attempt to explain why sacrificing quality, while seemingly beneficial in the short term, can become very dangerous in the long term.
Broken Windows 🔗
Simply put, in criminology, the broken window theory states that visible signs of crime and disorder foster an environment that encourages more crime and disorder. To demonstrate this theory in a more practical way, let’s consider the following apocryphal experiment where a new car was simply left on the street for a week. After the week passed, the car remained untouched. Consequently, the experiment was repeated, but this time the car had a deliberate crack on the windshield. Another week was left to pass and the car was completely destroyed.
If we take a closer look at the second round of the experiment, each person who damaged the car did not really change the state of the car that much. If the windshield was already cracked and someone else were to add another crack; it’s not really that big of a deal. But now consider repeating this over and over again, with each subsequent damage inflicted on the car being greater than the previous one. Pretty soon, the car ends up being completely wrecked. In contrast, imagine making the first crack in an otherwise pristine car, the difference becomes significant. This is an important point, because it is how significant the damage could be that dictates whether it is acceptable or not to damage the car.
What’s interesting is that this theory holds true for things beyond cars and crime. Let’s take software development as an example. If bad designs, wrong decisions, or poor code are left unrepaired, the quality of a given codebase is only bound to get worse. After all, how would a new set of “special cases’’ affect an unreadable one-thousand-line function already cluttered with “special cases”? Or what would another flakey test do to an already flakey test suite? It is these sorts of dynamics that, if not stopped, could grow to become fatal. Fortunately, the opposite also holds true. High-quality simple code will beget high-quality simple code. This is why it matters to pay attention to detail and to not let the small things slip. From elementary things such as code linting and formatting to more involved things such as choosing the right design patterns and abstractions. It is these sorts of subtleties that when executed well or rectified help produce, maintain, and improve quality.
Boiling Frogs 🔗
As coined by Daniel Quinn in The Story of B, the term “Boiling Frog" is a metaphor that describes a frog being slowly boiled to death. The premise is that if a frog is put suddenly into boiling water, it will jump out, but if the frog is put in tepid water which is then brought to a boil slowly, it will not perceive the danger and will be cooked to death. This metaphor is commonly used to reference our inability as humans to be aware of threats that arise gradually as opposed to all of a sudden. Or as it relates to quality, if its improvement is overlooked while complexity rises, it will be too late and too expensive to fix things once fixing them is no longer a choice but a necessity.
Let us again use Software Development as an example and consider the following scenario. Pepito and I are tasked with building an application to determine the optimal placement of products in a supermarket. To make things interesting, let’s assume that both applications will share the same user interface and achieve exactly the same results. However, the difference is that the code quality of Pepito’s software will be substantially better than mine. Consequently, this also means that due to my lack of quality I will be able to code faster and put my app in the hands of customers in two thirds of the time that it would take for Pepito to do the same.
Since the end user will never see the source code and the operation of the app will be the same regardless of who builds it, you might be asking why would anyone pay a quality premium for Pepito’s software? Well, the answer is probably not that many people, but actually everyone should. The reason is simple, good quality makes it easier to enhance and maintain software over time as complexity goes up. To put things in perspective lets picture the following situation. Just after a month of both applications being delivered, Pepito and I are asked to fix a bug, add a reporting feature, patch a security vulnerability, upgrade external dependencies, and write documentation. Naturally, this time around Pepito will be able to execute the tasks in a third of the time that it would take me to do so.
The main point is that as complexity increases, my software will only become more convoluted, slower to develop and prone to errors; or in other words, I’ll slowly start to boil. In contrast, Pepito will be able to manage complexity better by focusing on improving the meaningful and hacking away the inessential. This will not only enable him to scale and develop faster but will also help him create a positive feedback loop that reinforces the maintenance and improvement of quality.
Sanded Drawer Undersides 🔗
Back in the early 2000s, John Lesseter, the Chief Creative Officer of Pixar at the time, was quoted saying “we sand the drawers’ undersides” to reference the level of quality that goes into making a Pixar film. When I first heard this quote I was instantly intrigued, not so much because of the statement itself, but because they actually did it. Just think about it, in the grand scheme of things, sanding the undersides of some animated drawers that will appear for half a second on a film for kids won’t really have a material impact, if at all, on the final cut of the film. However, the symbolism of such an act does. Simply because it sets the standard of care and attention to detail that is required to be put into every aspect of a Pixar film. In essence, such an action captures perfectly the meaning of quality, which can be defined as the level of dedication and care that is put into the performance of a craft.
Going back to Software Development as an example, most of the time we develop an application we’ll figure out how to properly build it after we have finished building it. It’s only after our code has been shipped and it’s running in production that our poor design choices and wrong assumptions become apparent. This is why achieving quality can be so hard. Nonetheless, I believe that quality is not something to be achieved but rather practiced, or as Aristotle put it, quality is not an act but a habit. At its core, quality is an iterative process that involves having the humility to learn from mistakes, the drive to innovate, and enough resolve to not take the easy way out. Understanding this is crucial, because quality involves taking the time to go back and improve things as we find better ways for doing them.
To conclude, just as there is a time value of money, there is a time value of quality. Going back and improving things once the how becomes apparent requires some degree of investment, but as time goes on and complexity increases, such investment is sure to pay off with dividends. In contrast, failing to invest on the improvement of quality is equivalent to incurring a debt whose interest payments compound, and if not paid promptly, could lead to bankruptcy. The main point is that quality should not be the constant chase of perfection but rather improvement. Just remember to take care of quality and quality will take care of you.