Yesterday I read an article by Martin Fowler titled “Is High Quality Software Worth the Cost?” which really resonates with my experience as a software developer.
But (there is always a but), after sleeping it over, there is an assumption to which I disagree, and an economic issue that is not addressed. Following the example in the article, we have two teams, one writes with “high internal quality” and the other with “low internal quality”. The result is shown in the graph below:
The assumption (shown in the graph) is that the crossover point occurs in weeks, not in months. I disagree with this assumption, especially at the initial stage of product development. In these stage, which can take months, functional changes are required all the time in order to iterate fast and achieve product-market fit. At this stage there is little time to invest in quality – the bulk of the investments must be diverted to features, functionality changes, and user iteration.
Why?
Because we are not in the business of selling software (at least most of us aren’t). We are in the business of building product that people use, like, and will pay for. This is defined in the the article as “external quality”. I fully agree that investing in internal quality helps deliver external quality faster, but the cost of delivering internal quality is high. As explained in “The Mythical Man-Month” (and from my experience), software products (those that have internal quality) take from 3 to 9 times as much time to develop as in-house programs. Most products start as in-house programs and evolve to software products. If you invest from the start to create a software product you will be spending 3-9 times as much time to develop a feature as the competitor… and during that time money is being burnt. And there is a limit to the amount of money a team can use to find product-market fit.
Another assumption is that the cumulative functionality continuously increases, something we would all hope but in reality many times we add functionality, then change it, and even remove it.
Let’s visualize this in a chart. As I couldn’t find in 5 minutes a nice line-charting app, I had to use paper and pencil :-).
In the first period where the product is being developed there are multiple pivots, where many times functionality that was built gets thrown away and replaced by new functionality. A team that has higher internal quality can make up for the pivot faster (thus the drop for the higher internal quality is shorter), but as it takes more time to get to pivot point, it takes more time to achieve product-market fit. And this may mean failure to the whole project.
Let me give a concrete example: I have an idea that we should build a system to distribute widgets using blockchain and AI technology. I start with a web application because it’s the fastest path to get user feedback. After 2-3 weeks my app is running and I start gathering user feedback. Users love the idea, except for one thing – the interaction with the app is clunky on the browser and they really want an iPhone app. Most of the functionality I created is still relevant, but I will need to write a lot of things from scratch. If I had taken a lot of work on the internal quality of my web app, it could have taken me 2-3 months to get the feedback… and some (not sure how much) of the effort that went into the internal quality of the web app will be completely wasted.
So in summary, and as the original article pointed, there is no good answer to when and how much you must invest in internal quality vs. external quality. But this decision must also take into account the phase of the product and how much product-market fit there is, because building an infrastructure for a web application that is later pivoted to an iPhone app is something that none of us wants to do.