Build TDD adoption through Support-First efforts

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.

Comments

• Anonymous
  January 16, 2007
  So if the support team adopts #1, what do I tell the development team that has no tests for 500,000 lines of code.  We can't seem to convince management that it is worth the time to stop new development for two months while we write some automated tests that the client will never know are running.

1. How do you convince management that we should be required to do this?
2. How do you convince developers that think it is a "nice idea" but they code "well enough without it"?
3. If you get past number 2 how does a team get started when the code base is already in place and it would take a fair amount of time to learn effective testing and then to build tests around the code and business logic?

• Anonymous
  January 16, 2007
  The comment has been removed
• Anonymous
  January 17, 2007
  To date, my problem has been that I write the code with tests and the support engineers ignore it. I come back in a few months and the tests are broken.