% fortune -ae paul murphy

Prototyping

Yesterday I suggested that "the programming language appropriate for a particular application is the highest level language in which the requirements can be fully and completely expressed."

To understand what this means for development organizations, first lets agree that specifications like response time limits aren't applications requirements - they're artifacts of SLA dominated organizations in which Systems grudgingly doles out minimalized support to business units who succeed at negotiating the budgetary system.

Beyond that, the way to start understanding this is by considering that the minimal information needed to describe how something works is invariant relative to the language or other method used in the description. In other words, if you had a complete description done using method A, it should be possible to use information about two methods, A and B, to write a mechanical translator converting your description from A to B -for example, from "C" to binary.

So if a UML requirements specification were actually complete, a UML compiler should be able to turn it into working code and so eliminate the need for coding - and product testing. Unfortunately there have been quite a few "software from pictures" products, absolutely none of which have worked for non trivial applications. Why? because nobody's yet come up with a sufficiently precise modelling tool that wasn't actually a programming language.

What people have come up with are powerful prototyping tools allowing you to interactively produce complete, working, applications - many of which could, and sometimes do, go directly into production.

Many, however, can not, and for three main kinds of reasons: generally relating to exceptions handling, scaling, and efficiency. Thus some user guru's Microsoft Access application may work for her but:

1. not have things like range limits or other error trapping because she knows what to put where and feels no real pain on needing to correct the occasional error;

2. a lot of the interior components, things like the DB and screen APIs, may not be available in larger environments; and,

3. processing efficiency may be a non issue to a user with a few thousand records on a 3Ghz PC with lots of RAM, but become a killer issue on a machine with only ten times the CPU and RAM, but 1,000 times the users.

For production ready prototyping environments, however, none of these issues apply and a working system is therefore its own specification and equivelent to the application - ending all ambiguity and avoiding the escalating communications failure characteristic of the traditional IT development project.