In the pre-guttenberg days, printing the Bible was done by teams of monks with a lot of hand crafted labor—even the paper and ink had to be made. Many hands over one year were involved in the production of a single bible. Software development is the same way.

 

IT shops range from having 4 to 100 developers working on the same application. With Applications, the source code can be years older, sometimes over ten years old. A developer who is asked to make a change needs to understand what is already there before making an alternation. The monks, although their job should have been easier as they were typically copying, had trouble because of the drift of an evolving language and the metaphorical nature of the bible–it wasn’t easy to know what the original meaning was. Some IT shops have developers create a document that is supposed to document what a program does, but everyone knows that those documents aren’t very accurate. At best they work as a 10,000 foot map. A huge value that micro tests bring is that the developer’s intent is “baked” into another program which tests the production program. The term “production program” refers to the program that is intended to be installed into production so it can be used by users. The test program is never put into production since users aren’t interested in executing micro tests. Having micro tests gives developers something the bearded and bald monks of the medieval times never had: an automated check that raises a flag when the production program deviates from some past developer’s intent. When a micro test fails, the developer then re-evaluates her recent program changes and looks closely at the both the test program and the production program to decide if the failing test needs an update or if her strategy is flawed. This is an advancement over the monks whose only recourse was to take a break, consult with others, and pray and ponder the matter. Micro test automation is an advancement over such medieval practices such as manual testing since they give developers feedback within minutes. Now let’s get busy and start creating them.

 

Later in this series, we’ll fill you in on situations that developers face which complicate doing TDD. But before that, let’s get the players onto the field and find out Why Devs Don’t TDD.