Friday, August 7, 2009
(Images adapted from flickr users Duke TIP and Patrick Beeson)
One way in which software engineering differs from other engineering disciplines is that in software the prototype is often confused with the real thing.
Nobody looks upon a prototype 1/50th scale model of a bridge and says "Looks done, let's drive trucks across it now." Yet in software development such sentiment is commonplace -- "Looks like it's working, all we have to do is clean up the bugs and ship it!"
If this were merely a misunderstanding between the programmers and the business-types it would be understandable, but the unfortunate fact is that it's often the programmers themselves who believe this. This attitude of hack-and-patch contributes to the general lack of quality of software compared to other engineering disciplines and this is compounded by the perceived low-cost of failure. Structural engineers don't say to themselves: "If it doesn't work we'll just patch it in the field." Electrical engineers don't say: "Ahh, sort of works... we'll upgrade it after tape-out." It has never occurred to a mechanical engineer that they could hide their lack of quality control by creating an automatic update system that secretly updates their wares behind their customer's backs.
For software engineering to be done right -- like in every other creative discipline -- time and space have to be allocated for building *disposable* prototypes. There is no progress without failure, but you don't have to subject your customers to your failures either.