No Trade-off Between Quality and Speed
Discovering the hidden harmony between quality and speed
Cutting corners
In the world of software engineering, there is no perfect software. It's all about finding the solution that has the right balance of trade-offs. Being a good engineer requires making decisions with careful consideration. It’s a main part of our job. The problem starts when people start making bad trades. Sadly, this is a common problem in many software teams.
I got unlucky (or lucky?) to work on multiple legacy projects in the past. I felt the pain and consequences of badly designed software. Code with no tests, unreadable code, and lack of solid architecture. Risky changes, time-consuming modifications, and impatient customers. I think many of us can relate. The main reason for these disasters was: quality has been sacrificed. The pressure was on, features were rushed, then everyone was suffering.
The bad trade
Software teams often trade quality for speed. They try to gain some time by giving up quality. The hard truth is: there is no trade-off between quality and speed in software. Low quality means low speed.
Developers try to save time with:
Skipping testing
Leaving refactoring later
Not writing clean code
Releasing in big batches
Neglecting to set up proper CI/CD pipelines
Not using Infrastructure as Code
But they won't be faster. They will be much slower. Gaining time with any of these is just an illusion. They’re short-term solutions that lead to long-term problems. They ultimately result in slowing us down, reaching the point where expensive rework becomes the only option.
The myth of choosing only two
There is a famous misconception coming from the project management world. It originates from the quality-fast-cheap triangle. It’s used by many software people out there. It’s also called the “project management triangle“. It states the following:
You can only choose two from these three: quality, fast, or cheap.
This is not true. You can’t pick two. By following this, if we want to deliver features fast and cheap, then we just need to sacrifice quality. If we keep applying this principle, we would always sacrifice quality to gain speed at a low cost. Sounds like a good trade, isn’t it?
The reality is different. This triangle doesn’t work like that. If one dimension is compromised, the others will follow. Once we sacrifice quality, we lost. When you trade quality for speed, you get less speed, not more. And the more you do, the slower you will go. On top of that, you can’t execute a trade between quality and speed. They are the same sides of the coin, having a high correlation.
Quality vs Speed
Software quality consists of two main parts: how well it’s designed and how much it meets the customer's expectations. Internal and external quality. We can get internal quality by producing maintainable, well-tested, and clean code that enables fast changes and safe deployments. It’s all about reducing the mental load to continuously adapt the code. Our speed depends on quality.
External quality is the other part of the story:
Quality is value to someone, who matters - Jerry Weinberg
Our most important task is to make our customers happy by delivering value. We can only make our users happy if we frequently verify our software with them. Otherwise, we can spend weeks building something they don’t need. To frequently verify our software, we need to be early with our changes. We need speed. Practices like working in narrow end-to-end stories, Continous Delivery, or On Site Customer enable quick feedback loops and fast delivery of software. That is what external quality is about. Doing and verifying things early and often. So the quality will depend on the speed of our processes.
As you see, our speed depends on the quality, and the quality depends on the speed. It’s a self-reinforcing cycle that can’t be traded. Once you lower any of them, you lose the other. To craft better software you need to move fast. To move fast you need to craft better software.
The traits of elite teams
For almost a decade, the DORA (DevOps Research & Assessment) has been analyzing what makes high-performing engineering teams. Every year they come to the same conclusion: teams that focus on quality perform much better than the ones that neglect it.
From their reports, I've collected the key findings on what high-performing teams have in common:
Strong emphasis on continuous delivery practices
High focus on testability - remember TDD
Deploying multiple times per day
Less than an hour lead time for changes
Utilizing loosely coupled architecture and teams
Having strong organizational culture for high quality
Based on their findings, it’s evident which direction we should be heading towards.
How do we gain speed?
The solution is simple: focus on quality and improve your processes.
To improve processes: reduce any communication overhead. Remove silos. Forget working in isolation, and embrace Pair and Mob programming. Create a team with all the capabilities. One team member might be better than another. They should teach each other. The architect should teach others to be an architect. Testers should teach others to be a tester. DB specialists should teach others to be a DB specialist. You don’t need a separate DevOps, Architect, or QA team. You neither need full-stack developers. You only need a full-stack team.
Once you have your team, then focus on quality. Because you can only go fast if you go well. Remember that quality and speed go hand in hand. Our professionalism also relies on the ability of learning. Producing software is continuous learning about the domain. The smaller the steps you make, the more you can learn. Test-Driven Development, Continuous Integration, and Frequent Small Releases are your friends. For most of your problems, you can find solutions in the practices of Extreme Programming.
Conclusion
There is no trade-off between quality and speed. It’s quite the reverse. You need both to achieve high performance. To reduce cost, you need speed. To get speed, you need confidence. To gain confidence, you need quality. We should all remember this when next time we plan to sacrifice quality for speed.
High Quality is the speed, low total cost & low stress.
Very good article