Saturday, March 20, 2010

Who would go welding without a drawing?

Imagine a mechanical workshop. You come with a problem that they will solve. What do you expect? You expect to work together with them, roughly in the following five-step procedure:
  1. Specify. You will describe the problem in the form of a functional specification
  2. Design. They will make a drawing
  3. Pieces. They (possibly multiple people in parallel) will use the design to select and manufacture pieces
  4. Product. They will weld the pieces together into the tool you need
  5. Test. You test it, and it may require minor adjustments
Now imagine a software workshop. You come with a problem that they will solve. What do you expect?
  1. Specify. You will describe the problem in the form of a functional specification
  2. Product. They will make the software tool
  3. Test. You alpha test, they fix, you beta test, they fix. Repeat until satisfactory
How come this list contains only three instead of five steps? And why is the last step always causing so much pain? Could this difference be the origin of why so many software products fail? What is the real difference between software and hardware development?

Rather than trying to solve the software problem at once, first imagine a hardware workshop that works like this:
  1. Specify. You will describe the problem in the form of a functional specification
  2. Product. They will weld materials together into a tool
  3. Test. You test, they fix, you test again, they fix. Repeat until satisfactory
How likely would it be that this procedure is faster than the five step procedure? How obvious is it which pieces need to be welded together? Will this allow multiple people to work together on the product? And how much work is the testing for you? How much waste is produced in the process? You would not accept this kind of quackery! And my point: you should not accept it from a software workshop either.

A good software workshop would use the same five steps the good mechanical workshop uses:
  1. Specify. You will describe the problem in the form of a functional specification
  2. Design. They will make a (modular) design
  3. Pieces. They (possibly multiple programmers in parallel) will use the design to build and select software modules 
  4. Product. They will use the modules to build the software you need
  5. Test. You test it, and it may require minor adjustments
Investment in a design will result in a solution that will truly solve your stated problem, and not require endless iterations to get right. It may look like a slow solution, but that is deception: you will actually get a result that gets you where you want to be, also when you have new additional requirements in the future.

I'd like to thank a former colleague at Bruker AXS that gave me this nice comparison. I know he wishes to remain anonymous on the 'net. Image credits: Dystopos on Flickr.