The Reality The User Dreams...
(C) 1981-1999 Riviera Software Inc. All rights reserved. Published with the authorization of Michel Kohon.
At the time Step-By-Step was in many ways a revolutionary way to look at the process of creating software. Many users' group and organization in the Hewlett-Packard world asked me to come and give lectures. Technology keeps on changing, but the core concepts of Step-By-Step seem to be standing still.
Please don't be fooled by the way I talk about users, programmers or programs. Where you read "user" you can certainly think of Product Manager, Marketing VP or Customer. When you read "programmer" you want to think Engineer, Developer or Project Manager. When you see "program" think about object, module or product. It's all the same.
When it comes to software quality what counts is your ability to deliver products, programs or projects on time, on budget and on specs. Using Step-By-Step as a compass you can do it.
- To explain Step-By-Step for end users
- To specify the Step-By-Step method for IT professionals
- To give Step-By-Step's main advantages and its possible adverse consequences.
- The reality
- The users' dreams (also called requirements)
The reality is a difficult thing to change, to transform or simply to understand. Users' requirements are difficult to change transform or simply understand. From the reality, the system analyst or programmer will try to develop a system that fulfills the users' dreams. Users can see the impossibility of their trying to accomplish this themselves.
The Reality The User Dreams...
- Users do not know "specifically" what they want
- Users do not think enough about exceptions or specific circumstances
- Skilled users sometimes do not exist.
One way to reduce these problems is to educate the users and to improve the skills of the IT staff in questioning users. But whatever is done to improve the situation, the facts obtained from the users are only a partial statement of their requirements.
The second way, extensively used in the "packaging" method, is to have endless interviews and studies. This investigative period is sometimes so long that the company changes its product lines in the meantime, creating a high degree of confusion in the requirements. The dreams tend to be a mirage.
Specifications tend to be too detailed for parts of the system, while lacking specificity for other parts.
System design is likely to generate a huge amount of paperwork consisting of the translation of users' requirements into program specifications, data base structure and paths of information in and out of the computer.
Program design will include all possibilities requested by users, from the most useful to the least, from the most complicated to the lease.
Detailed analysis is likely to discover that new functions are necessary, which were not seen before, meaning new programs, an increase in program complexity or design changes; in any case, the first delay in the project.
For interactive programs, he will have to think like a user, which is impossible because IT people are computer professionals.
The programmer will find some errors in the analysis, which will delay the whole project because an essential program will not work correctly on time.
Like the designer or the system analyst, the programmer would like to have a perfect system, so he will add beautiful but useless feature. This is called the "galloping elegance" syndrome.
This is also called the "Galloping Elegance" Syndrome
The type of business users are involved in determines the requirements. The business can be production, sales, marketing service, etc. Business can vary depending on season, crop, day or other factors.
The consequences for data processing from a change in business are new and different information needs. One way of taking these changes into account is to make an exhaustive list of the possibilities and program all of them.
We also said that it is difficult for a user to visualize the end result of a program, and even more difficult when it is an interactive one. Why is this so?
A program is not static. The actions it performs vary dynamically, depending on the information that is entered. 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.
The following two concepts are the foundation of Step-By-Step:
- To discover the users' actual requirements and to program all of them
- To give the programs to the users as soon as possible.
Nothing really new, but keep these two concepts carefully in mind. You will be surprised by the methods of achieving them.
What are we really interested in? To know what the user wants.
If he knows why, you can start the second part of the study; otherwise, you will have to go into a problem-solving routine. Problem solving is also a service; we advise you to use some of the KEPNER & TREGOE methodology to help you. In any case, you will have to find out why the payments are not cashed quickly enough.
We seem to be far from data processing. Not so. We are only processing non-structured information (the users' explanation) without a computer. But you know that the computer is not the most vital element for data processing.
Anyway, going back to the example (a real situation, by the way), we still find that "the invoices are not processed quickly enough". It appears that our user needs an invoicing system. Mind you, if you had asked, "What do you want?" he would probably have answered, "I want an order entry system", because this was his overall, long-term objective, and because it will solve his cash problem.
The confusion arises partly from mixing long-term objectives with short-term problems. If you could provide, overnight, an order entry system, including the invoicing package, there would be little or no problem. You would have solved the user's immediate problem.
But, of course, you cannot implement it overnight, not even in a fortnight. You will conduct a long study and come back with phase one of the project ready, i.e., the order input. You will not solve the problem, which has created the need of your expensive intervention (the cash is still not arriving faster).
Both you and the user will be very frustrated.
If you can provide, overnight, the Order Entry system...
- Identify the problems which have created the need of IT assistance
- Set long-term objectives as well as short-term ones.
Identifying the long-term and short-term objectives will permit you, with the users, to draw a line of actions within an overall strategy. You will move from point A to point Z through points B, C, D, ...., with each point being an objective. But how to order these points?
To provide a solution to the top problem means that you will give the maximum result in a minimum of time, and you will repeat this with each successive point. Order the objectives from the maximum payoff to the minimum. These will be your steps. Now you can make your design and organize the system in a structured way. Do not go into details. Remain flexible.
The document you are preparing is the final report. It consists of:
A step is usually a move of two to three programs, but it could be more. To write the programs, you will have programmers, but never enough. Why is this so? Because the demand (user's request) automatically adjusts itself to the offer (programmer resources). We won't prove this here, but you can believe it.
The strange thing is that the more programmers you get, the more complicated the resulting system will be. This is the very well known law stating "adding people to a project will delay it in direct proportion to the number of added men". The explanation is easy to state: by increasing the offer, you increase the demand.
The Offer-Demand Law: it applies to DP, as it applies to apples.
The only logical way to escape this dilemma is to limit the offer. How can we do that?
One way is to limit resolutely the number of programmers working on a project.
This approach is already frequently used, but for different reasons: to shorten communications and avoid misunderstandings, and to add flexibility and improve responsibilities. This is a method we still recommend using.
A second way is to limit explicitly the amount of time allocated to a program or system.
Let's imagine for a moment that we've said we have two weeks to program our step with the existing manpower. No more than two weeks. How can we best solve the problem in the amount of time given? The natural way will be to put on paper what the MUSTS and the WANTS are. If both can be produced in two weeks, we will program both, but that is unlikely. Therefore, how do we determine which steps will be MUSTS and which will be WANTS?
It really depends on their nature. If they are, or some of them are, necessary before we can program the next step, they have to be part of the NEXT STEP MUSTS. If they are not necessary before step X, insert them into the MUSTS of step X. The most important objective is to find the absolute MUSTS which can be produced with the CURRENT staff in a limited period of two weeks.
Well! That's it! There is nothing more to Step-By-Step. However, we will come back to two important questions.
More than two weeks is too much. Generally, users do not wait for you. They have other activities, very often repeated on a monthly basis. Therefore, to give them the program(s), you will need another week, which means that the program(s) will go into operation only after three weeks.
Experience also shows that two weeks is a "manageable" piece of time, possible and realistic.
It is good to introduce Step-By-Step to the users. The more of a selling job you do before starting a project, the easier it will be. If the users do not want it, don't undertake the project at all, as users without commitment will never help you.
Use the MUSTS and WANTS method with the users. Look at all the problems - theirs and yours. Some MUSTS are yours. Explain why. Again, try to solve their problems. IT is amazing how often you will find that a program can be easily replaced by a simple manual procedure.
Challenge the users. Everything is a MUST for them at the beginning. Ask always and again - WHY? Quickly, some of these MUSTS will turn out to be WANTS.
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.
Try to imagine that in 2 weeks time, it is the End of the World
Like step-wise refinement, Step-By-Step needs a structured programming approach. Programmers can use almost any language to program in a structured way, with or without GO TO statements. It will be very dangerous to program Step-By-Step in an unstructured way, as the code, which will constantly change, will look like a war theater.
With Step-By-Step, unlike step-wise refinement, the analyst has to bargain with the programmer to obtain a workable piece of code in two or three days, then a second piece of code in a similar amount of time, and so on till the end of the step. This is a kind of sub-stepping, where the analyst has to play the user. It requires teamwork and discipline to keep the programmer from testing the exception module when the general one is not yet working.
... Will look like a war theater
A request may look like a MUST; the analyst and the users should determine whether it is. Both should remember that a MUST means that the program will not work when put into production. In other words, a modification needed a few days after the scheduled implementation is not a MUST.
It is the analyst's responsibility to plan this MUST for a further step. The users should remember that when they start using the program, they might discover that the request was irrelevant or inadequate. Irrelevant, because they might find that what they had proposed will make the program very cumbersome to use.
One of the major pitfalls with Step-By-Step is the possibility of stepping forward without clear final objectives. There is nothing more expensive than programming a step, then being obliged to re-program it during a further step. This will happen if the original objectives are absent or forgotten, and the result will look like a drunken man's walk.
It looks more like a Drunken Man's walk.
A second problem can come from "stepping" too quickly. If two weeks is the agreed pace, stand firm on that. Rushing will decrease the quality of the programs, in terms of reliability and documentation; it will also kill IT team communication, as few people will be aware of a step's content.
A third problem is a switch in priorities. It is in the nature of Step-By-Step that steps may be swapped, due to reshuffling of priorities. This is not dangerous, so long as the IT team is aware of it and ready.
When the first rockets were launched toward the planets, they were fully programmed. Everything was automatic and followed an unchangeable program. It all seemed logical, as all the parameters needed to find the target were known: the distance between planets, their relative speed and weight, the rocket's acceleration, weight, ... But the project failed. The objectives were not reached.
The next rocket generation included a new feature. Technicians were able to change the rocket's direction slightly during the flight to counteract the non-programmed consequences of the environment's reactions. This time the objectives were reached.
Implementing an on-line system in any enterprise is like sending a rocket toward a moving object. You need to adjust and control the direction. This is Step-By-Step.
... is like sending a rocket toward a moving object; you
need to adjust and control the direction. This is Step by Step.
Michel Kohon first published Step-By-Step in 1981 when he was the European Community CIO for Cargill Inc., the largest private company in the world. Kohon continued on to create MIRAGE, the first network DBMS for PCs. In 1987, after serving as Director of Business Development for Tymlabs, Kohon created HotKey/3000 a product that allows users to switch applications on HP3000 computers. In 1994 Kohon was hired as CTO and EVP for the Commercial Software Division of O'PIN Systems, a Healthcare software provider of Decision Support and Report Distribution tools.
You can find Step-By-Step on-line at www.opin.com and www.robelle.com
Michel Kohon is now the CIO at the American Academy of Ophthalmology. You may also be interested in his expansion on Step by Step: the Product Development Process (read the MS Word document).
Footnote:
* Prof. E.W. Dijkstra introduced step-wise refinement as part of the whole
Structured Programming revolution. Nowadays in the Object Oriented paradigm we would
rather talk about Unified Modeling Language.