Most of the teams and organizations I coach are working on using agile methods to improve their software development approach. Somewhere along the way, someone has realized that there must be a better way… either better than chaos, or better than bureaucracy. Over the years that I have been practicing agile methods, I have come to believe that quality is not negotiable.
The problem is this: when you have a defect in your work, you have no way of predicting how long it will take to remove the defect and remove it in such a way that it never occurs again. This is because the process of understanding a defect is unbounded: it is investigatory and exploratory and experimental. Once the defect is fully understood, the solution becomes clear and therefore estimable. Until that time, a defect represents an unknown amount of risk.
Before I started using agile methods, and in particular Test-Driven Work, I built software poorly. I delivered software which had unknown numbers of defects. I would often find myself trying to implement a feature (something of value) only to be thwarted by a defect in the software built so far. Until I could fix the defect, I was blocked from adding in the new feature.
The moment I started using Test-Driven Work to build my software, was the moment that I could start accurately predicting how long it would take me to build new features. I started delivering defect-free software. (Yes, it’s possible!) I delivered a complex multi-threaded, guaranteed-delivery, message-oriented-middleware framework that went through QA and Pre-Production testing with zero defects found. It was in production for two years before an obscure multi-threaded non-critical error was found… and none after that for a few more years. This sort of level of quality should be normal, not something to brag about.
Test-Driven Work depends on a clear understanding of how to make good tests. It also depends on an extremely high level of professional discipline. And most importantly, it depends on a supportive organization and management.
Often times, management, marketing or sales will put pressure on a development organization to “just get it done”, “don’t worry about doing it right”, etc. Unfortunately, most developers and development managers have not been instilled with a strong sense of professional ethics. Much more often than not, the response of the developers will be “yes, sir!” and then to go off and build crappy software that on the surface satisfies the pressure, but in the long term ends of sinking the organization.
How does this happen? It’s simple. Every time the developers sacrifice quality for schedule/cost/features, they incur a debt. Sometimes this is called “technical debt”. I like to call it lying.
Despite my preference for the more direct terminology, the term “technical debt” is a useful euphemism. As you accumulate debt, you have to make interest payments to maintain the debt. This shows up in the workarounds, the design cruft, the inelegant solutions, and ultimately in the slow down of the team in implementing new features. It is the cause of the industry’s propensity to rebuild products and systems from scratch every 3 to 5 years, and occasionally it is the cause of the failure of a business.
The only way to deal with technical debt is to confront it directly. First, the development team needs to start to refuse to compromise. No new work will be done without adhering to the highest standards of quality. Secondly, the team must start to clean up the old stuff. Doing this takes, courage, time and therefore money.
While I don’t recommend people lose their jobs for this, I do recommend that people look for other work if their organization is not willing to make this transition.
On a softer note, I also acknowledge that sometimes people make honest mistakes that end up introducing defects. This is fine… just make sure that as individuals and as an organization you are investing the time and effort to make sure this happens less and less frequently. Training, reading, practice, collaboration, all can help with this process. One can’t go from poor quality to perfect quality instantly… it can take time to make the changes necessary.
Here’s a software-specific article that articulates these ideas exceptionally clearly: Why Expensive Bugs are Cheap to Fix.
Here’s a follow-up article about technical debt.