Programming: No Pain == No Change
Slow QA cycles and bugs feel “normal” - until you see a better way.
🔒 Hello, this is Valentina with a premium issue of the Optivem Journal. I help Engineering Leaders & Senior Software Developers apply TDD in Legacy Code.
The invisible problem in programming
Just like traveling between towns by horse wasn’t a pain until cars existed, many software development companies see bugs and slow QA cycles as normal.
Often, when we have a current way of working, we don’t see it as inefficient or painful - simply because there’s nothing to compare it to.
Think back to when people traveled between towns by horse. The slow pace wasn’t a pain point - cars didn’t exist. Only when someone sees a car does the horse feel painfully slow.
Many companies work in software development the same way people used to travel between cities by horse. If you ask, “Is there a problem? Anything wrong?” they’ll say, “There’s nothing wrong. This is how it is in every company I’ve worked in.”
When someone traveled by horse, if you tried to get them to see the pain point, they wouldn’t see the pain point unless they saw the car. To help people see the problem in software development, you need to show them the car - a better way of working.
To convince management, if they don’t see a problem - or if you can’t communicate it - you can’t make any arguments.
Waterfall with Manual QA - The messy reality
The way most teams work is in silos, essentially in phases. There’s the requirements stage, then development, then QA. By the time QA engineers finish testing, they end up reporting a series of bugs. Some are regression bugs (existing functionality broke), and others are functional bugs (feature isn’t working as specified due to misunderstandings between developers and QA engineers).
Regression bugs:
Regression bugs are often seen as “just how things are,” but the real problem isn’t the bugs themselves - it’s the wasted time. Developers have to fix them, QA retests, and the cycle repeats over and over. Time spent on regression bugs isn’t contributing to feature development - it’s simply wasted.
Functional bugs:
Functional bugs happen when QA and developers interpret requirements differently. QA says, “You’ve implemented this, but it’s not working as specified.” Developers respond, “Actually, it is.” Often this ends up with the PO as the judge. In many cases, the developer’s understanding is wrong, which means we have to repeat the cycle of rework and testing. And even then, we’re still not fully sure whether the developers truly understood the requirement. So again, this is wasted effort - time spent going in circles instead of building features.
Relative Cost to Fix Bugs
Bugs (both regression and functional) are much more expensive to fix when detected late in QA or in production than if they were caught early. When speaking to management, point out that the slow feedback loops cause delayed bug detection.
And what’s even worse is that the cycles repeat, especially in the case of regression bugs. Now, what’s the solution?