author : Kent Beck

Kent Beck has distilled much of his wisdom and experience of writing Smalltalk code into this book of guidelines. These guidelines cover a range of coding topics, including: structuring behaviour using small methods, using of state and temporary variables, using Collection objects, formatting code.

The guidelines are structured using the now-popular Pattern Language approach, with catchy names for the patterns (to promote an expanded vocabulary), explanations and discussions of the problems and appropriate solutions, and pointers to other related patterns.

Some of these guidelines are new to me, and even the ones I had previously worked out for myself benefit from being written out explicitly and named. A must for every Smalltalk programmer.

Kent Beck has collected together his Smalltalk publications from journals such as OOPSLA and Object Magazine, and his famous columns from Smalltalk Report, with introductory comments putting them in historical perspective. (At least one of the papers must have been OCR'd from not very good copy -- it would explain some of the more surprising typos.)

There is a little overlap between this and his Smalltalk Best Practice Patterns, but here we get more depth and background, and correspondingly less breadth. The collection makes a fascinating historical document on the development of Patterns, from one of the originators. And there's some good stuff to learn about Smalltalk, too.

Yet another "How to do Software Development" -- but with a difference. Extreme Programming, or XP, takes into consideration what programmers do normally, what they do under stress, and what they like to do -- write code. And tailors the process to deal with these uncomfortable facts.

Some of XP fits in with conventional RAD (Rapid Application Development), designed to solve the problem of change: the business may independently change direction whilst the system is under development, and customers don't knowing what they want until after the system is delivered (and whatever it is, it's usually not that system!). So, factor the development into tasks, get the client to prioritise them, and then deliver as much as possible in the time allowed. Also, deliver incrementally, and so encourage feedback and change based on experience with the actual system. (Beck points out that early delivery also helps the cash flow.)

There are other parts of XP that are frankly heretical -- like delaying design decisions as late as possible until they're needed -- but Beck explains cogently why this actually makes sense. When developing software in the presence of change, those future design decisions might never be needed, because the project will have changed direction by then, so doing them early and unnecessarily is just a waste of money. And since the other parts of XP allow design changes to be made much more cheaply than conventional wisdom allows, the development doesn't get trapped by bad or wrong decisions.

The focussing of the whole code development around pair programming, unit testing and continuous system integration is fascinating. This helps give XP its great flexibility, but as Beck admits, continuous integration probably limits the development team size to at most 10 in practice. But one thing RAD shows is that a team of 10 working at full speed can accomplish prodigious feats, so this might not be as much of a handicap as it appears.

Beck makes an excellent case for XP -- which he has used successfully in practice. It is designed to cope with all the things conveniently ignored by most development methods: changing and uncertain requirements, team personnel changes, and maintenance being the biggest part of the project. He is also careful to describe cases where XP cannot work.

If you have a smallish development project with uncertain or changeable requirements, XP is definitely worth a look. And at least I now know that thing I like doing with code -- fiddling about, tidying it up, extracting commonalities, making it cleaner -- is a valid part of the process, and even has a fancy name -- I'm refactoring it.

Extreme Programming is a new way of building the right software, and building it fast, to a high quality. It's been tried on real projects, and it seems to work (it does require the development team to be relatively small -- ten or so programmers -- so no silver bullet yet for the more humungous software developments).

Whereas Extreme Programming Explained concentrates more on the actual coding side, this volume covers more of the client involvement, planning, estimating, and management aspects (and does assume you are familiar with the XP concepts described in the former book). Those are not always the most exciting of subjects, but the authors' clear and refreshing style makes this interesting, and makes the whole XP process sound terribly plausible.

Inspirational. I now want to rush out and join an Extreme Programming team. And I'm not even that fond of coding!

Test-Driven Development (TDD) is the idea that you write the tests first, then write the simplest possible code to pass each test. This gives short, well controlled iterations (small test, small addition of code), and always-working code (except for the short time when it fails the new test). I rather liked the idea when I first heard it, especially if you think of it as writing not tests, but (executable) specifications, then coding these up. But I was unsure how it would work in practice. After all, if your test case for the addition function is "2+2=4", then surely the simplest possible code that will pass the test is just to return 4 (no matter what the arguments)?

And the answer given here is, yes! Because there's another important part of the TDD process that hadn't been in the brief descriptions I'd previously heard, and that's refactoring. And one of the code "smells" that should be refactored away is having special constants, like that "4". So, write the test "2+2=4", write the simplest code (return "4"), then refactor (remove the constant "4", but still pass the test, so actually implement addition).

Beck also mentions the approach of "triangulation", having two independent tests, say "2+2=4" and "3+5=8", so the the simplest possible code has to be closer to the "real" solution. He claims not to use this approach much, but I must say it appeals to me: it might help you to think of special cases such as boundary cases right from the start.

Overall, this is a nicely written book, as the "by example" approach explains very nicely how to think up tests, which order to implement the tests and resulting code when you think up more than one at a time, and how to do the refactoring. There are also pointers to how to skip some steps (clearly, in an example as simple as testing "2+2", you almost certainly wouldn't write code that just returned 4, then refactor it; you would write the "real" code immediately), and how to backtrack to the "purer" form when those trivial skipped steps nevertheless lead you astray.

Yet another good step in the Agile Development approach.