Change Should Be the Ally of Quality
Join the DZone community and get the full member experience.Join For Free
In The Beauty of Testing, Steven Sinofsky writes:
…great testers understand one the cardinal rules of software engineering—- change is the enemy of quality.
This is not a cardinal rule. This is a outdated and obsolete mode of thinking. Change is how you discover great UX. Change is how you refactor and reduce technical debt. Change is how you incrementally improve both your product and code quality.
Maybe that’s too obvious, and clearly Sinofsky isn’t arguing for static software. More nuanced (and the rest of the piece provides that nuance) would be “change inevitably introduces bugs, and bugs reduce quality.”
This too I take issue with. Your codebase should be verifiably better after you fix a bug: you’ve found a shortcoming in your automated tests, so you add a test, and maybe refactor some stuff as well. Or, you’ve identified a bad experience, and can change it to be better in a controlled manner. A bug is an opportunity for improvement. Without bugs, it can be very difficult to improve.*
It can be difficult for anyone who hasn’t worked in a codebase with extensive testing to understand this. In most cases, fixing bugs is playing whack-a-mole. Whack-a-mole is unacceptable to me. Every change we make at Cozy is making the code clearer, simpler, better tested. It’s making the product smoother, faster, and more intuitive.
Change is necessary; it is up to you to determine if it is a friend or foe.
If you’re practicing disciplined development and automated testing and not creating many bugs, good job! This post isn’t for you :)
Published at DZone with permission of Rob Galanakis, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.