Afterwood

Now that people are beginning to venture out again, some of those meetups which have been in stasis for the past few years are starting to reappear. I continue to work almost entirely remotely after thankfully being turfed out of the office back in early 2020, and as such need to look closer to home for some in-person programming-related social interaction. Last year, somewhat desperate to get out again and meet like-minded people in-person, I attended a whole bunch of programming conferences, and that did turn out to be incredibly soul filling, but also quite an expensive exercise for a freelancer. (The bar bills were entirely self-inflicted, though.)

One meetup that resurfaced at the tail end of last year has been doing several sessions on practising TDD. Many of the attendees haven’t done it before and so my presence is more for the purposes of networking and lending an extra pair of hands. Even though I started practising TDD almost 20 years ago, I wouldn’t want to presume I have nothing to learn and, as it’s done in pairs, I know I’ll always learn something when pairing with a new partner.

I hadn’t noticed until a couple of sessions in that there hadn’t been any mention of books on the topic. Back in the mid-2000s, when I first became aware of TDD, there were two books which I immediately snapped up – Test Driven Development: By Example from Kent Beck and Test Driven Development: A Practical Guide from David Astels. It had been a while since pulling either book down from the bookshelf but I remember them both being very useful to me in getting a firm grounding in the practice and so I wondered if their omission was on purpose: perhaps they hadn’t stood the test of time?

Hence, before opening my mouth at the next TDD oriented session, I thought I would go back and at least read Beck’s book again to see if suggesting it would be useful or not. Many people prefer videos to the written word these days, so the audience for that format was likely to be small, but no video tutorials had been suggested either, so maybe there was a whole conversation about what the modern authoritative sources are? (At the time of writing there hasn’t been another TDD-based session to present to, so the answer will have to wait, for now.)

Like many of Beck’s books, TDD by Example is only a couple of hundred pages long but packed with content. The first part of the book covers the mechanics – the ‘by example’ bit – while the latter looks at the practice from a patterns perspective to explore the different approaches to writing tests, forces on the design, refactoring, etc. Reading through his money example was an absolute joy, far more than I remember first time around.

What I’ve always enjoyed about Beck’s books is the commentary that goes alongside the main thread. It’s in this background commentary where the real meat of the book lives. Even though the example is relatively simple, he is still forced to make numerous decisions about how to tackle the problem, such as how to break the problem down – when to go forward, sideways, or even backwards. He talks about TDD giving you courage and by seeing many of the micro-decisions he’s making for each test you get to see how that’s possible. One thing the book makes very clear is that the practice is not dogmatic; yes, there is a surrounding structure, but there are different paths depending on whether you already know where you are heading, e.g. Obvious Implementation vs Triangulation.

So, in summary, yes, I believe it totally stands the test of time and deserves the status of being regarded ‘a classic’.

In contrast, Dave Astels book tackles the subject in reverse, i.e. concepts followed by a lengthy example. He has far more tooling-specific sections, which has dated it somewhat. However, what his book really achieved was to address the naysayers that exclaimed that you can’t write a GUI test-first. Even 20 years later, I still hear that argument and modern UI frameworks are so much more amenable to being test-driven than they were at the turn of the millennium. It also helped me cement the notion of seams that Michael Feathers introduced in Working Effectively with Legacy Code as I tried to apply the same ideas to a legacy C++ GUI application written using an old-fashioned framework.

Should I be surprised that re-reading Beck’s book was possibly more enjoyable second time around than the first? Probably not, if we consider what Italo Calvino proposed in his article ‘Why Read the Classics?’ [Calvino86] The article, which is a precursor to his book of the same name, lays out what he considers makes a classic text. Of course, he was talking about real literature, not books on programming, but there are certainly many parallels. Number 4 on his ever-evolving definition of a classic is:

A classic is a book which with each re-reading offers as much of a sense of discovery as the first reading.

Likewise, Number 6 suggests that I can probably look forward to subsequent readings that will continue to bring pleasure and knowledge:

A classic is a book which has never exhausted all it has to say to its readers.

To date my attitude to reading generally sees me only make a single pass through a book. From that point on I may refer to it again, perhaps numerous times, but usually only to remind myself of specific points, such as when citing it as part of my own writing. What I never do is go back and read it again from scratch with the intention of unearthing new perspectives. Time feels too short, and the corpus of programming works too large to dwell repeatedly on the same texts, but that approach now feels decidedly transactional. Even for some technical books I feel I’m missing out on the opportunity to take the journey again, only older and wiser, but hopefully not complacent.

References

[Calvino86] Italo Calvino (1986) ‘Why read the classics?’, republished 12 October 2023 and available at https://www.penguin.co.uk/articles/2023/10/why-we-read-classics-italo-calvino

Chris Oldwood is a freelance programmer who started out as a bedroom coder in the 80s writing assembler on 8-bit micros. These days it’s enterprise grade technology from plush corporate offices the comfort of his breakfast bar. He has resumed commentating on the Godmanchester duck race but continues to be easily distracted by emails and DMs.