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.
Geplaatst door op
Labels: , ,

2 reacties:

  1. There is a big difference between welding and software though, a change in welding might take hours or days to change but in software it would take seconds.

    The other issue is in the software specification phase, it is hard to know what the clients want as they don't know and they often don't understand or appreciate a solution until they see it and use it.

    ReplyDelete

  2. Thanks for your insight, Andy!

    There are certainly differences between hard- and software setup, but they are not as large as most people think. Badly designed hardware becomes expensive to copy and so it is naturally avoided. Many people do not see that badly designed software may be essentially free to copy, but becomes expensive to maintain.

    Software changes can only be done quickly if the design has been right from the beginning. This forms an important bridge to the second half of your remark: specifications that are probably incomplete are an extra reason to make sure the design is right, because you just know things will have to be added later. Anticipation is the art of the software architect.

    To have frequent interactions with the customer, agile development can be a great help. And even using agile development a true design is required.

    Except, of course, if what they want is a hack... Unfortunately customers often think they need a hack, but most often they really don't.

    ReplyDelete

Subscribe to: Post Comments (Atom)