Another attendee of my training tells me “The quality of my application is exceptional, adding TDD is an overhead that brings no added value.”

You statement makes me ask a few questions. How did you get the exceptional quality? Is your application finished? Will it be changed? How do you plan on maintaining exceptional quality?

How did your application get to be exceptional?

This is certainly good news that your product is exceptional. People have been building great products without TDD for quite a while. This does not mean there are not areas where you can improve on your next product, or future revisions to your already exceptional product.

Before or during my training classes, I ask engineers to tell me where they spend their time. How much of the effort is coding? How much testing and debugging? The numbers range from 30% testing and debugging to over 85%. Industry numbers that I have seen tend to be in the 50-60% area. At 30%, that is a lot of time. At 85% it is appalling. How did you get the exceptional quality? How much of your time was spent testing and removing problems?

Recall the physics of debug later programming (DLP) from this article.

I also ask people “How long does it take to find a bug?” No one has ever answered the question because there is no answer. Some are easy to find; some moderately hard to find; some really hard to find; and others evade being found altogether. Wouldn’t you say this is a high risk?

How can we as professionals work in such a way that we accept this huge risk for our employers? We have no idea how long it will take to find a bug. Is this irresponsible?

TDD, on the other hand, is working in a predictable rhythm. Where we prevent defects (many of them) so we don’t have to hunt them down later.

At your company you have teams that work using TDD. One has 30 programmer years of effort invested and a bug list that fits on half a page of paper. They spend their time adding new capabilities to the product, not chasing bugs. Would that be valuable to you?

My product is finished, what value is TDD?

You have a working system, with exceptional quality? I am happy to hear it. If your system is working and you do not need to change it, you should have no problems. Systems generally start out simple, with good quality. It is hard to keep them that way without automated tests.

It seems though that most products are never done. Releases end, but products tend to have a life of their own. New requirements come in. Hardware platforms change. Products evolve. Is your product is really done, or you are done with your product?

What about changes?

Maybe you have to change the system, or hand it over to someone else to change it. Changing existing code is risky. Any change can have unintended consequences. It is possible for an individual to keep their creation alive and well, though much more difficult for someone new to take over an existing system. Do you plan on being married to your system for the rest of your professional career? Most engineers don’t want this. Experienced engineers know it won’t happen. The engineers in your company that do sustaining work wish they had he tests for your code.

The power and beauty of adding tests is that the engineer expresses what the code is supposed to do in the production code and the test code. The tests are a powerful form of documentation. They capture the knowledge you put into building the system into a very accessible form. The tests capture assumptions and subtleties. Oh yeah, you can also run the tests to make sure that the system is still working as desired.

Many systems start out simple, clean and low on defects. If you have been around development a while, you probably agree that it’s hard to keep simple and clean as the change requests come in and the time to market pressure mounts.

The strategy you follow for existing legacy code (of any quality) is to add tests if you are going to change it. When the knowledge of the system is only in documents and the production code, you have significant risk that you will miss the some assumption or subtlety and introduce a side effect defect.

My product is not finished yet and I don’t have tests

For all the reason given above, there is no time to start TDD like now. Add tests along with the new code. If you need to change your product, add tests to lock in current behavior; then test-drive in the new behavior. I’ll give you an out; if your deadline is looming, don’t start now. I’d rather not see TDD become a scapegoat. Start with enough time to get used to TDD and or get someone to help you.

Oh Yeah, TDD is Fun!

I keep forgetting to mention this. TDD is fun. Manual testing is boring. Learning how to build your product using a series of repeatable tests is a good challenge an has a good pay off. I recommend you also look at TDD and the Gamification of Testing. It might shed some more insight on why many people are enjoying their work more with TDD.