Step-By-Step™

Published on September 7, 2016


 
 Liked
 
 
 Unlike
 
 Step-By-Step™
 Unlike
 2

 
 Comment
 Comment
 0

 
 Share
 Share Step-By-Step™
 Share
 0

Michel Kohon
Follow
Michel Kohon
President

Step-By-Step™

By Michel Kohon

(C) 1981-1999 Riviera Software Inc. All rights reserved. Published with the
Authorization of Michel Kohon.

FOREWORD

The original Step-By-Step was written way back in 1981. Some believe I am the Agile’s
Grand Father. May be. So let’s go through Memory Lane. This is vintage writing. I did
conference, thanks to a small startup called Hewlett-Packard, the world over. That was
back then. Enjoy!
Since then the philosophy upon which was based SBS has sort of infused inside society
and is now called Agile. Steps are called Sprints. What I call “Packaging” is now called
“Waterfall”.
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 strong. 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 count is your ability to deliver products, programs or projects on time, on
budget and on specs. When using Step-By-Step as a compass you can too do it.
BACKGROUND
The objective of this document is to:
• Explain Step-By-Step for end users
• Specify the Step-By-Step methodology for IT professionals
• Give Step-By-Step’s main benefits and its possible drawbacks.
TOWARD STEP-BY-STEP
To understand Step-By-Step, it is essential to analyze the IT function (back then, we
talked about IT :). Like all other human beings, IT Engineers have to deal with two
concepts:
• Reality
• 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.
Packaging
The traditional IT approach to such a problem has been:
• Obtaining the users’ requirements
• Formalizing the requirements
• Designing a system which would deal with all aspects of the requirements, and define
programs covering all requirements
• Programming and implementing all these programs together or, at least, to try.
Obtaining the requirements
• Users do not know "specifically" what they want
• Users do not think enough about exceptions or specific circumstances
• Skilled users sometimes just do not exist.
One way to mitigate these problems is to educate users and to improve the skills of the IT
staff when questioning users. But whatever is done to improve the situation, the facts
obtained from users are only a partial picture 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 become a mirage.
Formalizing the requirements
From a written document, users can only visualize some general ideas of a system, not
details or consequences.
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 mostly consisting of the
translation of users’ requirements into program spec, data base structure and data
pathways in and out of the computer.
Program design will include all possibilities as requested by users, from the most useful
to the least, from the most cumbersome to the least
Detailed analysis is likely to discover that new functions are necessary, which were not
seen beforehand, meaning new programs, an increase in system’s complexity or worse:
design changes; at any rate, the first delay in the project.
Designing/Programming
From the system analyst’s specs, the programmer will create a program, probably to meet
the technical objectives rather than the users’.
For interactive programs, he will have to think like a user, which is impossible because
IT people are computer professionals. (Note: obviously nowadays we might have some
UI specialists involved… but not always :)
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.
STEP-BY-STEP
As we said earlier, users’ requirements are likely to change. Why is that so?
The type of businesses users are involved in determines the requirements. The business
can be production, sales, marketing service, etc. Business can vary depending on season,
crop (hey, I worked for Cargill when I wrote that :) , 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 users 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 some hacking jargon. The same applies to mathematics, astronomy or
films. How can we visualize a film from a script? This is why the sooner you show a
program to users the better it will be for their understanding.
The following 2 concepts are the foundation of Step-By-Step:
• discovery: discover the users’ actual requirements and to program all of them
• ownership: give the programs to users as soon as possible.
Nothing really new, but keep these 2 concepts carefully in mind. You will be surprised by
the methods to achieving them.
Getting the requirements
What are we really interested in? Knowing what users want. 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 be asking users is: "What are your problems?" They might tell you: "We can’t
recover payments quickly enough. We have to pay too much in financing costs."
If they know why it is, you can then 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(c) methodology to help you. In any case,
you will have to find out why the payments are not cashed quickly enough.
It seems we are far away from data processing. Not so. We are only processing non-
structured information (users’ explanation) without a computer. But you know that the
computer is not the most vital element for data processing.
Anyway, going back to our example (a real situation, by the way), we still find that "the
invoices are not processed quickly enough". It appears that our users need an invoicing
system. Mind you, if you had asked, "What do you want?” they would probably have
answered, "We want an order entry system", because this was their overall, long-term
objective, and because that would solve the cash issue.
The mixing up arises partly from confusing long-term objectives and 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 user’s short term
problem.
But, unfortunately, 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 users will be very frustrated to say the least.
Breaking the Problem into Steps
Obtaining the user requirements is a two-fold process.
• Identify the problems which have created the need of IT assistance
• Set long-term objectives as well as short-term ones.
Identifying long-term and short-term objectives will allow you, together with 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, …., 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 (max payoff for minimum cost), and you will repeat this with each
successive step point. Order the objectives from the maximum payoff to minimum. These
will be your steps. Now you can draft your design and organize the system in a structured
way. Do not go into details. Remain flexible (few years later “they” would call it “Agile”
:)
The document you are preparing is the final report. It consists of:
• Long term objectives
• Objectives for the first and all following steps
• Sub-systems or programs related to each step, and priorities.
When this document is approved, you must write the programs - those of the first step, of
course!
Programming a Step
Some comments before starting programming anything.
• The final goal is the program, not the analysis. So, till the program or its results are in
users’ hands nothing is completed.
• There is a general law governing the whole world;: the offer-and-demand law. It
applies to IT, as it applies to apples (may I remind you Apple was still in a garage
when I wrote this). We will see how.
A step is usually a move of two to three programs, but it could be more. To write these
programs, you will have programmers (that’s really a generic term for a multi-functional
team), 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 got to 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" (probably from
Dijkstra). The explanation is easy to state: by increasing the offer, you increase the
demand.
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 (less for web based systems). 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.
How to establish a Time Limit?
In our examples, we took two weeks, and this was not arbitrary. We think that two weeks
is a manageable period. Less is difficult and dangerous, as stepping too quickly will
permit neither the proper education of users nor the corrections to the programs.
Programs must still be of outstanding quality, and, of course, you need some tools and
structured design to step correctly.
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.
(I have changed that to 3 days while developing web products during the glorious 1990 in
San Francisco)
How to Establish the Discipline?
This is the most difficult part of Step-By-Step, since it deals with human willingness -
both the users’ and the IT team’s willingness. Here are a few tips, which might help, but
success depends more on the company and personalities than on anything else.
It is good to introduce Step-By-Step to users. The more of a selling job you do before
starting a project, the easier it will be. If 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 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.
STEP-BY-STEP PROGRAMMING
Step-By-Step can be applied to implementing a particular program. The methodology
known as "step-wise refinement" is not very far from Step-By-Step.
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 (we were in the 70’s… much debate about GO TO). 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.
STEP-BY-STEP: PROS AND CONS
One of the major bonuses for users is that they take control of the product as soon as
possible. This means that users can see the program reacting to their input. They can
visualize how it will work day after day. In general, users ask for small modifications. It
is a MUST, at this time, to avoid asking for and, therefore, to avoid making modifications
which are lengthy, or which should be included in a further step.
A request may look like a MUST; the analyst and 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.
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.
CONCLUSION
We like to make analogies between data processing and other technologies or sciences.
Analogies are very important, as you often create a new technique in your field, which is
very old in another field. Knowing this ancient technique may save you a lot of time.
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.
Kohon first published Step-By-Step in 1981 when he was the EEC CIO for Cargill Inc.,
the largest private company in the world. Kohon continued on in 1982 to create
MIRAGE, the first network DBMS for PCs and launched his first start-up called DataSoft
International. In 1987, after selling dataSoft, he went on to serve as Director of Business
Development for Tymlabs, Kohon created HotKey/3000 (Kohon’s 2nd startup) a product
that allowed users to switch applications on HP3000 computers. In 1994 Kohon sold
HotKey to O’PIN and become the CTO/EVP for the Commercial Software Division.
Kohon retired in 2005 to the country where he was born: France. Kohon is a proud dual
Citizen of 2 great countries (and states): Texas (USA) and France. Kohon now spends
time coaching French Tech. Startups and developing web-based services.