A month or so ago I was asked to carry out a technical book review on a yet un-published book. I have to admit that I was really flattered that someone would ask me to do this. I couldn’t see any problem with this as I knew the domain area, have read all the main books that are already out there discussing this and I love to read. The one thing I didn’t take into consideration was what I would do if I didn’t like the book! How do you tell someone who has put so much effort into a project that you don’t like it? It didn’t matter to me that I have never met the author, I still agonised over every word I had written. Was I being overly critical, had I emphasised the good points enough, how do you phrase “I can’t understand what this is supposed to mean” or “this example is terrible” in a way that doesn’t offend the author? In the end, after spending most of my Easter break on this, I gave up and just sent in the review. Next time, if anyone ever lets me write anything about their book again, I will try to remember that even though I love to read I don’t like everything I read.

Many software engineers believe a detailed solution should be created and meticulously verified as solving the problem before any code is written. On the other hand, a few of us believe that we haven’t solved the problem until we deliver the software and prove it works. This difference in when we believe the problem is solved causes us to view the requirements document differently. I believe requirements should describe the problem, not the solution, because the problem isn’t solved until we’ve got code running.

– Don Wells, Don’t Solve a Problem Before You Get to It, IEEE Software, May/June 2003 (Vol. 20, No. 3)

I have to give a talk next week on Test Driven Development. I only have 10 minutes in which to put my point across and I am keen to find an easy way to explain it. I’m having difficulty coming up with a good example – something that will make sense to the non-technical people in the audience but won’t be perceived as overly simplistic or incorrect to the technical people.

In the past I have always used internet examples to describe software projects. I was really surprised when people couldn’t follow my e-commerce examples. I had assumed that the whole world would have shopped online by now and would understand what I was talking about. It appears that this is not the case. It also appears that lots of people don’t consider web-sites to actually require software to drive them!

If I use a bad example I will completely loose the audience and they will think that Test Driven Development is a stupid idea. Time is running out so hopefully I will be able to come up with something soon.