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.

Smell

After product deliveries following early iterations, the customer has no complaints, but during the late iterations, the customer complains about many things from all iterations.

Solution

The customer must be “coached” sufficiently to provide honest and substantial feedback from the very beginning of the development process.

– Amr Elssamadisy & Gregory Schalliol, Recognizing and responding to “bad smells” in extreme programming

It’s seems that the main road to Carrickfergus from Whitehead has been closed because of a gorse bush fire. There have been quite a few woodland and forest fires over the last week due to the very dry weather. So now I know what happens if we have a couple of weeks of dry, sunny weather.

Are there essential differences between the male and female brain? My theory is that the female brain is predominantly hard-wired for empathy, and that the male brain is predominantly hard-wired for understanding and building systems. I call it the empathising-systemising (E-S) theory.

– Simon Baron-Cohen, They Just Can’t Help It [via Russell]

So Russell has an extreme male brain. I decided to take the test and apparently I have a balanced brain – one that is equally systematic and empathising.

This morning Marty gave a talk on “Free Software is the Future” at the NIOSC open day. I didn’t get to hear the talk as we set up an exhibit to help promote Kasei and the Belfast Perl Mongers which I was left to sit at. The main focus of the day so far has been on Linux. None of the attendees I’ve spoken to have ever heard of Perl. Could be a long day.

What incentive do you have to do a job quickly or correctly if you are being paid by the hour? Why would any company that bills by the hour want to improve their internal processes?

I have to work with accountants and lawyers who have hourly rates. They can’t tell me in advance how long any job is going to take because no two jobs are the same. I’m not a lawyer or an accountant so I don’t know how long it should take to complete certain tasks. When someone tells me that it took them 40 hours to produce a report what can I do other than believe them?

I have come to realise that this issue of trust means that I have to keep detailed records of the length of time spent in every meeting and phone call – because they are the tasks that I can monitor. When I receive a bill I check the cost of these against my records. If I find discrepancies I start to doubt the whole bill. For example, recently I received a bill for a three hour meeting. Now, I was at the meeting and it only lasted for 2 hours. So, if the company I’m working with can’t bill me correctly for a meeting that they know I was at how can I believe them when they are billing me for 40 hours of work that produced a report?

I agree with Dave. It is annoying when the writers seem to have ignored what has happened in the past. I know that characters don’t have to speak the truth all time but to bring it up twice in one episode…

One of the things that can be a problem is that people can think that patterns are unreservedly good and that a test of a program’s quality is how many patterns are in it. This leads to the apocryphal story of a hello world application with three decorators, two strategies, and a singleton in a pear tree. Patterns are not good or bad – rather, they’re either appropriate or not for some situations. I don’t think it’s wrong to experiment with using a pattern when you’re unsure, but you should be prepared to rip it out if it doesn’t contribute enough.

– Martin Fowler, Patterns, IEEE Software, March/April 2003, Vol 20, No. 2

Marty has redesigned his blog. I haven’t been able to look at it yet without recoiling in horror at the bright green colour. But it suits Marty.