TDD Shoots Cowboy off His Speedy Horse

There is a cowboy developer\programmer, speeding through the wilderness on his horse. He can produce code faster than anyone.

Give him a rough sparse user specification and he will have a working solution in a matter a days.

So, if you were to enforce TDD on this cowboy, of course he will say that it slows him down. It will slow him down significantly.

He has never done any design in the past, now you are asking him to design his whole application.

It’ like taking him off his horse and removing his Stetson. You are trying to change him from a cowboy and on the way to being a professional. Do not expect that to be easy.

Of course he will fight against it. He can produce an application in a month, whilst the same application written with TDD will take 6, 7, or eight weeks, certainly a longer period than the cowboy takes.

Do not get me wrong when I say the cowboy can write an application in one month. It’s is usually an illusion. The customer will like the look of it. The customer may even test a few of the features and say WOW. What the customer does not know, that underneath that pretty UI is a pit of snakes and scorpions just waiting to bite.

Customer: Can we have a feature added?
TDD: No problem, should be ready in two days and I can prove that I have not introduced any bugs.
Cowboy: Dunno about that. The coding is fixed. You’ll have to be responsible for any bugs that are introduced. You really should not be introducing changes at this late stage

Manager: We’ve got a new Developer joining the team. Can you get him up to speed on the project?
TDD: Yes, the Tests serve as a ‘living’ fully up to date design document. The new Developer can quickly see the purpose of classes and methods. The new Developer will become productive in just a few hours.
Cowboy: I can’t really show someone how my code. (Secretly I do not know how it works myself. I’d be embarrassed to show the code to someone else.) We don’t need a new Developer. I can finish off. Just give me pizza and let me work through the night and weekends.

Team Leader: Change the algorithm in a method to make it more efficient.
TDD: Not a problem. This is called re-factoring. We do it all the time during TDD.
Cowboy: Change one of my methods? Do you realise that it will have an impact on the rest of the application? This could set the project back by weeks.

Oasis, thanks for your comment on 27 Sept 2009

I just want clarify what I mean by refactoring.

Suppose we have the following method.

        public Price GetPrice1(List prices, string requiredItem)
     {
         Price priceFound = null;
         foreach (Price price in prices)
         {
             if (price.Name == requiredItem)
             {
                 priceFound = price;
                 break;
             }             
         }
         return priceFound;
     }

The code can be refactored in the following way.

First, the method signature must NOT be altered.

The code within the method can then be improved. For example a decision may have been taken to implement LINQ for objects.

All the tests should still pass and have no knowledge of the fact that the method has been changed.

      public Price GetPrice(List prices, string requiredItem)
     {
         return (from n in prices where n.Name == requiredItem select n).SingleOrDefault();
     }