{"id":20,"date":"2004-07-14T23:28:35","date_gmt":"2004-07-14T21:41:48","guid":{"rendered":"http:\/\/www.craigmurphy.com\/blog\/?p=20"},"modified":"2004-07-14T23:55:39","modified_gmt":"2004-07-14T22:55:39","slug":"doing-the-simplest-thing","status":"publish","type":"post","link":"http:\/\/www.craigmurphy.com\/blog\/?p=20","title":{"rendered":"Doing “the simplest thing”"},"content":{"rendered":"

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

I was using DUnit<\/a> 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”. <\/p>\n

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<\/a>, raised his hand and said: “Building a class isn’t the simplest thing!” <\/p>\n

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<\/a> code, the Delphi 8<\/a> code or the Visual Basic.net<\/a> code.<\/p>\n

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.<\/p>\n

I realised that what I had done was the simplest thing the could possibly work in this xUnit testing framework<\/em>. It wasn’t the simplest thing that might get the job done.<\/p>\n

Similarly, in an earlier re-run of the same session, Andy<\/a>, pointed out that my<\/em> 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<\/strong>. <\/p>\n

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. <\/p>\n

I’ve just googled under the bus count<\/strong> only to realise that it’s not defined anywhere.<\/p>\n

I’m using the phrase to mean: <\/p>\n