Some Initial Impressions on GOOS and TDD by Example

I recently finished reading TDD by Example by Kent Beck and am almost halfway through Growing Object-Oriented Software(GOOS) by Steve Freeman and Nat Pryce. They are ways of focusing the mind. They take the complex, often overwhelming problem of building a software system and break it down into small manageable problems.

I think one of the most important things I learned from reading TDD by Example is that I can decide how big step I'm comfortable taking with each test and thus how much of the problem I have to worry about at any given time. This means that if I'm comfortable with the problem I can take out big chunks of it, if I'm not, I can move in tiny almost imperceptible steps. At each step I can decide how abstract I want to make the implementation, maybe I hard-code everything, maybe the right abstraction screams out at from the screen. I can do the thing that makes the test pass and worry about making it “right” in the next step. Mastery of TDD includes knowing when to slow down and let the tests guide you to the right abstraction.

It also includes constant refactoring. Getting the test to pass is writing the first draft. Refactoring is revising the draft.

The walking skeleton is the image that I think about when I think about GOOS. It's the idea of always having something ready to ship from the beginning, even if it doesn't do anything. Software development is about building a system of connected pieces of software. The sooner you can put pieces together, the better. It reveals any pieces that don't fit as early in the process as possible when there's less pressure to get something out of the door.

You make a different kind of problem for yourself when you start a project in the way advocated by GOOS. It takes a while to get to the first failure and the first passing test but that first passing test is of the whole system(a simple version). It's setting the project up for success later by finding as many of problems as early as possible.

I wish I had a walking skeleton as the first sprint for every project I've been a part of.

Both books have the authors making a list of tasks before starting to work and updating the list as they work. This is probably the biggest thing they do that helps them stay focused on the small manageable problem in front of them. It's something I started doing immediately that has helped me right away.