Step-by-Step Method

Traditional development methods with their slipped schedules and frustrated users are not the best way to do programming. The Step-by-Step method is one antidote for these failures; it was developed by Michel Kohon when he was an MIS manager in Europe (Michel is now CIO of the American Academy of Ophthalmology in San Francisco. He lives in Berkeley, California. Contact: mkohon at aao.org).

We at Robelle published Michel's original "Step By Step" paper in a book that we published in 1982. Here is an excerpt from this classic paper :

A program is not static ... it is a moving body and is unlikely to be adequately described without using jargon. The same applies to mathematics or astronomy or films. How can we visualize a film from a script? This is why the sooner you show the program to the user, the better it will be for his understanding.

If you ask a user "What drug do you want?" he will answer, "Vitamin C". In fact, the question is too specific. What we should ask the user is: "What are your problems?" He will perhaps tell you: "I can't recover my payments quickly enough. I have to pay too much in financing costs". It appears that our user needs an invoicing system. If you had asked him "What do you want?", he would probably have answered, "I want an order entry system." If you could provide this overnight, there would be no problem. But, of course, you cannot. You will conduct a long study and come back with phase one, i.e., the order input. You will not solve the problem (the cash is still not coming faster).

You must identify both the long-term and short-term objectives, then break them into manageable steps. Solving the top problem first means that you will give the maximum result in a minimum of time, and you will repeat this with each successive step. Order the objectives from the maximum payoff to the minimum. The final aim is the program, not the analysis. So until the program or its results are in the hands of the user, nothing is completed.

A step is usually a move of two to three programs. You will have programmers, but never enough. But the more programmers you add, the more complicated and delayed the resulting system will be. How can we escape this dilemma? By limiting resolutely the number of programmers and the amount of time allocated to a project step. Find the absolute musts which can be produced with the current staff in two weeks. Never go back on the two weeks allowed. It must be done in two weeks. Try to imagine that in two weeks' time, it will be the End of the World. Users will laugh, but they will, as well, appreciate your concern.

Implementing an on-line system in a commercial environment is like sending a rocket toward a moving object. You need to adjust and control the direction. This is Step-by-Step.