TDD by Example: Introduction

Summary

Beck tells a story. It starts with an unexpected new requirement. The CEO of the company they work for asks if the bond portfolio management system the company is selling could be changed to support multiple currencies. Ward Cunningham gets a couple of days to think about it.
The Dollar object originally had calculation and formatting responsibilities but those have been refactored away. The built-in classes of Smalltalk could handle the calculations. The formatting was done in the user interface classes. The Dollar object is just used as a counter in calculating something in the user interface that deals with averages. He tries to substitute Currency for Dollar and finds that it can support it. He then tries to see what happens if the currencies being calculated are different and finds that can also be supported. He runs the tests and after fixing a few failing tests he checks in the code.

Beck analyses the story. When the system was proved to be able to support multiple currencies, it multiplied the value of the system and thus the company that was selling it. This was because Ward Cunningham and his team were experienced making changes to the design of the system, they understood how valuable it would be to the business if they were able to make the system multi-currency, and automatic tests and good separation of concerns allowed them to make changes and have the confidence that their whole system still worked.

Beck then says that this kind of progress is possible for most programmers, except for geniuses(they do not need any method) and idiots(no method will help them). If they follow these two simple rules:

1. Write a failing test before you write any code
   1. Remove duplication

The rest of the book is about how complicated it can be to follow those two simple rules.

Commentary

It's a neat story. The good programmer because of his good programming has made a system that can respond to unexpected requirements from the business and deliver features that multiply business value.

The thing that sticks out to me is that are lines like:

After six months of careful paring, the resulting Dollar didn't have much responsibility left.

And

Ward and the WyCash team needed to have constant experience growing the design of the system, little by little, so the mechanics of the transformation were well practiced.

These quotes tell me of an almost ideal work environment for programming. One where you can spend six months carefully refactoring essential parts. One where your whole team believes this kind of thing is worth improving. One where the business stakeholders see the value in this.

Beck acknowledges my skepticism when he says:

Does this mean that if you are not one of the ten best software engineers on the planet and don't have a wad of cash in the bank so you can tell your boss to take a hike, then you're going to take the time to do this right, that such moments are forever beyond your reach?

I think about what is within my reach. If I'm pairing with somebody I may not be able always convince them to write a failing test first but I can always suggest it. And when I'm programming solo I can always do it. I may not always have the time to work on removing duplication, especially if it's not obvious duplication. I may not know enough of the domain to understand that the same concept is being encoded in two different places.

If I do these things maybe one day I can tell a neat story too. I was a good programmer and because of my good programming I made a system that can respond to unexpected requirements from the business and deliver features that multiply business value.