Breakthrough Idea: How to Prototype Software

Been thinking about this one for a while, and I got it.

Consider a software group writing a program for in-house use. The biggest problem is communication between the software group and the users. Creation of a dumb prototype is a well-known attempt to solve the problem. However, as I envision the creation of the prototype, I can see many problems potentially developing.

Essentially, time must be invested, people from two different departments must communicate, tensions may arise, and ultimately, the task of prototyping may be abandoned rather too easily at any time. The software group would like to abandon the task because it's not the sort of thing they like to do: they want to get on with writing the program. The users would like to abandon the task because they do not enjoy interacting with the software group.

In addition, the users have been assured by the software group that the writing of this software is really quite a simple and easy task that does not require the burdensome process of writing a prototype---imposed by the rather stupid types in management, at any rate. Naïvely, viewing the whole situation as a "simple, straightforward technical problem", the user group alludes with the software group in prematurely terminating the task of prototype-building, which in any case seems to be inordinately difficult for reasons that no one can quite understand. Happily, once the prototype task is abandoned, the software group can get down to the real business of writing the program and the user group can get down to their real job whatever it happens to be.

Unfortunately, the reason the prototype was difficult to write was because the task of the users that the software is designed to integrate with---a task which seems so simple to the software engineers that only a moron could be doing it for a job---is, in fact, complicated in a variety of subtle ways. Not to worry, all of the subtleties will turn up---later, after the software is written and tremendous work and effort has been put into doing so.

Okay, that's the problem. I know what you are thinking, "What a brilliant formulation of the problem!" However, let me modestly point out that the formulation of the problem is fairly obvious and well known.

Okay, here's the solution: we create super simple, super user-friendly prototype building software designed explicitly for non-programmers (i.e. "users") to use. Included with the product would be a "manual." (see, "Software; Ancient History in your encyclopedia for an explanation of this term.) However, instead of a nice, bound booklet with high-quality color illustrations, this manual would be online, that is to say it would be a living document.

Different versions of the manual would be written for people in different professions, the point of view of the manual being the process of getting some particular task done such as lawyering, being an accountant, or more specifically, deciding who gets to take out a loan to buy a house, helping someone write up a tax return, designing a of building out of steel, designing interior components like door handles for a car, etc.

Instead of a carefully crafted document designed to last for the ages, I envision a series of down- and-dirty versions of the manual. Scratch that, what I mean is there would be a core manual describing operations and then a variety of intros aimed at different professions. The idea being to not only tell people how to use it but to convince them that it's important to use it. There would also be a general intro for everyone, describing the perils of writing software without an effective prototype.