Software Engineering folklore says "Budget, quality, or speed - choose two." But, in the context of software development, I take issue with this rhetoric, as it concerns quality. In my experience, compromising quality is not an option; it's a foundational pillar upon which effective software development stands.
The Iron Triangle of Project Management
In management, we face difficult decisions. We have a challenging timeline. We have to deliver a whole mountain of scope. We work with inexperienced people. When faced with such a dilemma, we tend to apply the old mantra: "Budget, quality, or speed - choose two", illustrated next:
The illustration shows the typical dimensions impacting the software development process.
Speed: Time is invariably of the essence. Whether it's contractual deadlines, board expectations, or market entry strategies, time constraints are omnipresent.
Budget: we always have to balance our spending to what earn in return - ROI. Overspending without commensurate returns is futile.
Quality: this is a tricky one. This refers to both the visible and invisible quality of the product. E.g., the features of the product and the quality of the code. Consider response times and memory but also aspects like the ability to update often.
Now let's consider our options. We have three dimensions - speed, budget, and quality. What happens if we turn the dial on each? If we run this experiment for development, we realize one thing: Quality cannot be negotiated!
Allow me to argue.
Disregarding Quality
During my time as a software engineer, I've come to understand that there is a direct linkage between the three dimensions. The keystone in this relationship? Quality. Reduced quality affects speed, which, in turn, impacts the budget.
Consider an engineering project developed in Java I have been involved in. The team members were more junior than expected. So, development did not meet the management's expectations. That went on for a couple of weeks until one manager came up with a suggestion:
Why don't we halt this obsession with unit testing? It's slowing down progress. Let's rely solely on end-of-sprint QA.
Ignoring quality in the initial development phase might give an illusion of speed. The development might appear to take off - see the next illustration. Initial reports may even look great. Client demos run smoothly. Your team hits every milestone (I).
However, the illusion of initial speed gains soon gave way to a cascade of issues. Technical debt mounted, manifesting in bug-ridden, inefficient code. As time progressed, the cumulative effects became apparent: increased debugging efforts, catastrophic failures, and a compromised timeline.
Take Back Quality
The consequences of neglecting quality are well-documented. For, in the late 1990s, the $125 million NASA's Mars Climate Orbiter was lost due to a simple software error.
An investigation indicated that the failure resulted from a navigational error due to commands from Earth being sent in English units (in this case, pound-seconds) without being converted into the metric standard (Newton-seconds.)
Sounds like a good case for a test.
Look at the transformation practices from accelerate. Continuous delivery is at the heart of everything. Everything depends on having good engineering practices in place, from test automation to deployment automation.
But how can we get there if we disregard quality? We can't.
Consider a proven approach for measuring engineering excellence, the DORA metrics.
- Deployment Frequency: How often an organization successfully releases to production
- Lead Time for Changes: The amount of time it takes a commit to get into production
- Change Failure Rate: The percentage of deployments causing a failure in production
- Time to Restore Service: How long it takes an organization to recover from a failure in production
At a high level, Deployment Frequency and Lead Time for Changes measure velocity. Velocity, in this case, describes how fast can we move in a certain business direction. Can ideas be experimented on in production? Can we iterate on ideas fast? Change Failure Rate and Time to Restore Service measure stability. Stability describes how our product withstands adverse effects. E.g., outages, internal errors, and some transient system failures. Is our system self-healing, or does it require manual intervention?
The fastest way to build something implies ignoring stability.
The stable way to build something implies never changing anything.
The sweet spot is a stable system, that is also able to change with high velocity.
It should be clear that each DORA metric depends on having a high-quality code base. You cannot move fast and have a high velocity if bugs haunt your code. You cannot move fast and have a high velocity if your architecture is one big ball of mud. And your system is not stable if it falls over its own feet at every opportunity.
Investing in good coding practices and rigorous testing is vital. It ensures the longevity and maintainability of the software. It enhances customer satisfaction. It saves a considerable amount of time and resources in the long run.
Going forward - Learning from the past
The worst part is that this is not a new insight. Back in 1975, Brooks argues in the seminal book The Mythical Man-Month: rushing to meet deadlines frequently results in compromising the quality of software. It is crucial to prioritize quality over speed since low quality can ultimately cause more serious problems and delays: E.g., higher expenses for maintenance and system failures. Let me repeat: 1975!
The same insight is offered in Jones' Assessment and Control of Software Risks back in 1994.
Focus on quality, and productivity will follow.
While speed and budget are certainly significant, they should never be prioritized at the expense of software quality. The overall success of a project hinges on the balance and interplay of all three aspects.
As engineering managers and lead developers, adopting a quality-first approach should always be our mantra. Our role is to create value and deliver stellar software solutions that not only meet but exceed expectations. In the end, our reputation - and our work's standing - rests on the quality we deliver.
Top comments (0)