Book Review: Test-Driven Development By Example

Test Driven Development By Example is a Kent Beck book that introduces developers to the concept of driving feature development through the use of tests. This is not a new book on the subject, but it is the book that all developers should read. I have been developing using tests for quite some time, and I have used TDD techniques as part of my development methodology. Unfortunately it took me until recently to decide and read an actual book on the subject.

Kent uses two different examples to show the steps that take place in a Test Driven solution. The first example is a Money application that uses Java for its solution. The second example is an exercise in building your own xUnit testing framework for Python. These examples show the cadence a developer uses to go from broken test to passing test. Rather then describing theory for how to write tests, Kent demonstrates. While showing the reader what steps are made and why decisions are made, he is actually building a case for specific patterns. The third section of the book looks at specific TDD patterns.

This book does a wonderful job of demonstrating small focused tests. Create a test that fails, make it pass, refactor. Each chapter follows this pattern by focusing on a single task. Many of the chapters are less then five pages. They focus on a single test that needs to be implemented and the following implementation. This style may seem rather annoying at first, but definitely conveys the sense of being able to put down the book at any time. You can in turn pick up the book and quickly get right back into the exercises.

This is a great book for both beginners and experienced TDD developers. Beginners will get a great first lesson on how to TDD and why it can be as successful as it is. Experts can get reinforcement on why decisions and behaviors are important.

The Surplus

I was watching the TV show "The Office" and there is an episode where there is a surplus and a decision needs to made how the extra money is spent. If they don't spend the money it goes away, and the next year they receive less money.

Think of this, if you plan on running a 4 hour marathon. Suppose you are going to be done 30 minutes early. Would you run extra miles after the race so you can run for the full 4 hours? That would be silly. Then again would you slow down so that you hit the line an exactly 4 hours. This is the same surplus problem.

Suppose a software team committed to delivering a project in 9 months and they finished what they agreed to in 8 months? Looks like there is a surplus. How should that time be spent? Should the team get assigned a new project? Should the team be allowed to determine what they need to do over that 1 month period?

I see a very similar relationships between the three scenarios. Management funds projects and pays for it through money and resources. If the project cost the price or less, management gets what they asked for. If there is extra money or resources who gets to spend it.

I would think the team gets to spend the money or time. Lets face it as teams we rarely have extra cash or time. We also are more then welcome to accept more work. I think it is time to reward teams for being good at what they do. Let them decide how to spend the extra money. Lets face it we will probably prototype out something with a long term goal in mind.