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.
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
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 understand 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 know have 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:
The rest of the book is about how complicated it can be to follow those two simple rules.
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.
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 can be on the lookout. Every time I work on a new feature I can see if there are things I can refactor along the way.
I can do my best to get better at the things that are within my control and maybe one day I'll get the opportunity multiply the value of the software I'm working on by being able to quickly add one new feature.