Doing “the simplest thing”

I re-ran my An Introduction to Test-Driven Development session yesterday…to an exceptionally interactive and responsive audience. The slides are free to download here (1134k).

I was using DUnit with Delphi 7. I re-iterated the fact that eXtreme Programming and TDD extol the virtues of “doing the simplest thing that could possibly work”.

About half way through my session (which could easily have run on to 2 hours had dinner not got in the way!) a well-respected friend, Adrian, raised his hand and said: “Building a class isn’t the simplest thing!”

I had built a class that converts integers into Roman numerals. The first step was to add a method, toRoman, that took an integer and returned nothing. The second step was to have it return ‘I’ when ‘1’ was passed in as a parameter. Feel free to download the Delphi 5-7 code, the Delphi 8 code or the Visual Basic.net code.

Of course, he was right, building a class that has one method returning the letter ‘I’ is overkill. It’s not the simplest thing. Everybody knows that the simplest thing would have been a simple function with no class wrapper and no hint of object-orientation.

I realised that what I had done was the simplest thing the could possibly work in this xUnit testing framework. It wasn’t the simplest thing that might get the job done.

Similarly, in an earlier re-run of the same session, Andy, pointed out that my idea of the simplest thing perhaps wasn’t his. And herein lies one of TDD’s ironic facets: whilst TDD provides us with a great understanding of “how” a piece of code should be invoked, thus increasing the chance that somebody other than the original developer/programmer will be able to understand it, TDD can be an emotive process.

TDD will help you as far as your “under the bus count” goes, it will give you the most accurate form of documentation that you’ll ever have for your code base, but it won’t help you ring fence or blinker your programmers in to writing code the in the same way. But, since that’s not something any of us should relish, Borg-like programmers churning out the identical code for the same problem, it shouldn’t put you off TDD.

I’ve just googled under the bus count only to realise that it’s not defined anywhere.

I’m using the phrase to mean:

the number of people on a project who need to be run over by a bus, that will then make the project fail or incur a severe cost/time delay

If you are on a project with a team of one: yourself, then the under the bus count is one. If one person, you, is run over by a bus, the project fails, or meets almost insurmountable cost/delays. Of course, if it’s just you on the project team, you probably don’t need to worry about who’s going to be picking up the project after you’re gone!

Ideally, you should try to drive your under the bus count upwards, away from one. There should be no single point of failure, no empire-builders.

Go practice TDD, trust me, it works. It heralds a new confidence that will allow you to improve (refactor) huge chunks of your code base that you’d probably never want to touch citing “if it a’int broke don’t touch/fix it”…when you know perfectly well that the internal design is like a house of cards and won’t survive the next bout of customer change requests. It improves the quality of your life…there, what else goes this far?

Want to learn more about TDD? These books are highly recommended: