Search This Blog


13 June 2007

Comparing Software Development to Auto-mechanics part 2

My old MG is sick and I have a mechanic on the job. I thought it might be intertesting to compare the mechanic's project management processes to those used in the software/corporate project environment.

In the first post on the topic we have agreed that the work needs to be done, and he has given me a high level cost estimate.

Now, his next step is to give me a detailed analysis of the problem, a more detailed cost estimate and breakdown of the work.

Analysis and design

What I do
Go home and wonder where I’ll come up with the money

What he does
After I agree in general terms to the work being done and that yes I can afford it he tells me his next step is to work out a detailed schedule of work and cost estimate.

He opens the car up and pulls parts of it away. He looks under the bonnet, the chassis and behind the wheels. He then itemises the things that need work and estimates the effort it takes him to do each activity. He then sequences the activities so that the end job will be cheaper – eg by doing all the engine bay work at the one time, so he doesn’t have to pull the engine out more than once.

He broke the work into packages in case I couldn't pay for all of it in one go, and he prioritised the most important (safety) items first.

Eventually he has his first draft of the schedule of work and the costs.

His next step is to check it with an expert – in this case a manual for MG mechanics on how long each task should take (often within a range.)

Lastly he lists contingency items and adds them at the end.

How he charges
This analysis and design work is not charged either, but again it is time boxed and the potential gaps are highlighted in the contingency work.

Similarities and differences to software
Cars have been around for about 100 years and this method of dealing with estimating work has been around for at least 30 – 40 years. Software estimating should really be at this level of maturity, where there isn’t much that is really unknown except for:

  • Constraints to the requirements
  • Integration to legacies
So why is it that every estimation effort seems to be a finger in the air guesstimate?

Lastly, I particularly like the act of checking your estimates against an expert before handing tem up for review.

(There are systems and frameworks out there that can help you improve software development estimates, but not many people seem to be using them.)