Visit Agile Thoughts and register to receive free development, analysis, or leadership and management materials and learn to excel at developing software. I’ll also send information on my low cost email courses you can take via the internet.

Let’s say your job was to write a program that types to the screen the word: AWARE.

If we skip TDD, we just build our program to output the letters A, W, A, R, E, and we’re done.

Well, guess what? We aren’t done because a good developer realizes feedback is needed to prove the program works. So they run the program at least once to observe that it works. They may even confirmed their understanding of the spelling by looking at a dictionary or 1asking a colleague, and then publish the program.  Great!  Notice in even this simple example there is a problem–the developer did *manual* testing when observing the result to decide if the program worked. Two months later, a different programmer is asked to add a colon to the end to make the meaning clear.  They develop the code and again, manually look at the word “AWARE:” probably coming to the same understanding of the spelling as the previous developer, and then they publish the code.  However, often, the later developer is focused on only the colon at the end because that was their contribution. This third developer notices the colon and wonders whether or not that is important.  The developer ought to know NESS after the colon isn’t the intent because that doesn’t look like a proper word.  So she adds “NESS at the end of “AWARE” and in this case forgets to add the colon due to being distracted by a phone call or being interrupted by a meeting.  Later she runs the program, observes that the word “AWARENESS” is printed, and published the code.  Days later someone notices the colon was dropped and after several meetings they discover why this happened and contact the woman, interrupting her from other work so she can correct the problem.  Rinse and repeat: make the change, manual test, publish. Notice in all four changes, the developer intent is never recorded in an automated test but is instead done manually and at an individual’s discretion.

A wise woman once said, never plant more garden than your husband can hoe. More features is more complexity and more code.  The debt in test grows.  Code written this way is always unmaintainable unless your manual test budget is alway increasing.  Development is doomed to become slower, unless again, you’re development budget is always increasing so you can add more developers to work with difficult code. The unweeded garden becomes a jungle.

Next episode we’ll cover the same example but do it with Test Driven Development.