Edwin Ederle
Monday July 21st, 2008

Prototypes beat concepts

Prototypes beat Concepts!

The “concepts” posting reminds me of a question that I have asked myself for quite some time: Why doesn’t the software industry believe in prototypes? A new car model is initially built in plasticine. Later hand-crafted prototypes costing millions are produced before serial production starts. I have seen wooden mock-ups of Airbus fuselage sections. But the software industry produces rough concepts, detailed concepts, data models, and. specifications. Then they spend months programming according to the specification sheets. It’s easy to outsource this task – even to India. I am not surprised that the outcome is often unusable.

It’s not necessary to go as far as suggested in the FSC posting, (allowing a complete unsuccessful attempt), although this sounds perfectly sensible and pretty tempting. I like the idea of building a prototype using tools (such as Excel and Access), that allow faster more economical programming. Of course this prototype will lack some important functionality (Multi-user capability, security, processing of mass-data, speed, …), but the wooden model of Airbus doesn’t fly either. The prototype can be used to develop, test and refine algorithms, user-interfaces, workflows, reports, etc. and the costs of making mistakes or having to redesign some part would be much less. Often when reading specification sheets the end user cannot imagine how the final product will “feel”.

The prototype can then serve as a “live” specification, but not as anything else. And this is the main criticism, which I hear quite often: “This is a pure throw-away product; its development costs are wasted money”! But if a 30.000 Euro throwaway prototype improves a 700.000 Euro software project by 10%, it has paid off economically.


1 Kommentar zu “Prototypes beat concepts”

  1. Chris Wood (Tuesday July 22nd, 2008)

    I have a related suggestion for software development.
    In a couple of projects, I was free and clever enough to build a test system before starting on the development itself. It was good to get much of this work out of the way, before concentrating on the real product. This test system contained a sort of prototype, as well as masses of data (partly database, partly test data). The test data files were fed to the prototype and to the real product. The results were compared automatically. Any difference in results had to be explained and corrected (in the prototype or in the product).
    In effect, the product was being developed twice in different languages, one properly, the other quick and dirty. If both had the same bug, it could only be a design bug. At the end, one had an easily expandable regression test for checking that bug corrections did no damage.

Kommentar verfassen