I am convinced that Test-Driven Development is the single greatest hope that our industry has, as a whole, for improving the development and design of useful, practical, low-defect applications, and I find it frustrating that, in some places, it has taken off, while in other places, it remains a ‘nice idea.’
I saw a post on the newsgroups recently offering some ‘good tips’ for developers. These tips, largely a nice collection of tried-and-true practices, seemed like “yet another attempt” to fix the problem of bad code by making developers more aware of what to do well. Problem is that most developers don’t intentionally develop bad code. They develop good code, and then, in support, that code is expected to flex in ways that the original designer did not intend.
Over time, the code is modified through Quick-Fix efforts that may, or may not, recognize the original design. Opportunities for refactoring are not recognized because support teams are not paid to notice the original design intent… they are paid to fix the code. In doing so, they make mistakes that build up over time.
I think that test first development, as a SUPPORT discipline, would be the best way to highlight the need for refactoring code when it needs it, and not later, after it has becomed a tangled mess.
So, if you are in an organization that has not yet taken up Test-Driven Development, consider convincing your Support team to place these two rules into effect:
1) No code from development will be accepted into support without at least 80% code coverage in unit tests, and
2) No fix may be checked in for production deployment without all unit tests also working, and all new code getting unit tests.
Nothing will drive unit tests faster than making it a requirement of the support team, and nothing will lower the cost of ownership faster than recognizing the correct time for refactoring. I’m convinced that this small change can make a huge impact.