Do androids dream of electric sheep? Do managers on software projects have nightmares about plunging over waterfalls?
In the traditional view of the software development life cycle, a linear series of stages are completed in sequence, passing from requirements definition through analysis, design, construction, and testing. High-level design is completed before detailed design can be started. Problems are to be thoroughly analyzed and designed before questions about coding are considered. The development process proceeds smoothly from high levels of abstraction to low-level details, from the general and abstract to the specific and concrete.
Of course, it never really works this way. Still, the so-called “waterfall” model of software development continues to be hotly debated. It's a sometimes nightmarish part of our collective mythology. Once you go over a waterfall, your direction and progress are pretty much out of your control. You are going down, whether you like it or not. At best you can hope not to drown. I'll take some of the blame for long ago introducing such over-simplified notions, but, compared to the uncoordinated chaos reigning at the time, even these somewhat simplistic linear life cycle models were progress. Times have not changed all that much.
How software engineers and other programming types actually behave is that they are constantly getting ahead of themselves. No sooner do they see the title page on the requirements document and they are thinking code or screen layout. When they should be analyzing abstract usage scenarios, they're already thinking about icons for a tool bar. When they should be laying out communications paths through major modules, they start thinking about clever ways to utilize the applications programming interface.
This is normal. In fact, it's part of how normal people normally solve problems. In a sense, they work both ends against the middle, jumping forward and back between ends and means, bouncing up and down from high- level abstraction to low-level details.
But developers aren't supposed to work this way. Getting ahead of yourself in a long and complex project can create real problems. It makes it hard for you and your manager to know how far along the project is. Early commitments to details may later have to be changed, precipitating a cascade of other reworks and work-arounds. Getting into specific details too soon can also distract from the main work at hand.
Traditionally, developers and project leaders have had two basic options whenever this impulse to skip ahead arises. They could stick to the discipline and overcome the impulse, or they could give in to it and do the dirty deed before getting back on track. Either way has its risks. If you stay with the current task and ignore the distraction, important insights or ideas that could prove useful may be lost or forgotten. If you always go ahead and work on the details or the specifics whenever you think of them, you may never get back to the main thread. When you do, the thrust of your grand design may be lost.
What we really need is a life cycle model that takes advantage of the ways most people actually tend to think and work, but which keeps developers from becoming their own worst enemies. The problem is how to capture just enough information that can be used later without disrupting the flow of the current problem-solving activity.
My boss and I were recently working on the user interface design for a desktop applet, trying hard to act like disciplined software engineers applying a systematic interface design strategy, but we repeatedly tripped over our own tendencies to get ahead of ourselves. We kept getting these great ideas about detailed interface layout and behavior when we were supposed to be identifying abstract scenarios describing user needs.
Determined to be organized and systematic, yet committed to making the most of how we spontaneously work best, we started using “bins” to hold all those great little flashes that kept coming up at the wrong time. First developed for managing meetings, bins are a brilliantly simple tool for group problem solving. A bin is just a place—a flipchart or file or notepad—in which to record things that are not for current discussion or debate but which ultimately need to be considered.
Out of this we ended up devising a new conceptualization of the development life cycle. We call it the “feed-forward/work-back” model. It's a rationalized successor to various sequential development models, including not only the waterfall model but also so-called whirlpool models that take developers through an iterative spiral of steps. Feed-forward/work-back is actually one of those very small ideas that could make a big difference in how you work. In principle it could be integrated into virtually any software development life cycle model.
It's called “feed-forward/work-back” because of the kinds of loops it inserts into the development process. When you get ahead of yourself, you feed information forward but don't do the work. This is a feed-forward loop. When you discover an oversight or failure from an earlier phase or activity, you do the necessary work immediately. This is a “work-back” loop. Feed ideas forward, work your way back. That's it. Whenever you get ahead of yourself, you make a note to yourself and your teammates to reconsider something when you get to the appropriate point in the process, wherever that is.
Just think of each phase or activity in the software development life cycle as having its own in-box. It doesn't matter what particular life cycle model you are using, how many activities it has, or even whether it is strictly sequential or loops back on itself. For each designated phase or step or activity you create a conceptual container, an “in-bin,” to hold things to be looked at and worked on at the appropriate time.
It is important to create an actual record or file of some sort to serve as the in-bin. If you're using informal group methods, put up a sheet of flipchart paper for each phase or activity. If you do something called “Physical Design Validation” in your software development life cycle, have a sheet labeled “Physical Design Validation—In-bin.” If you are using document processing or computer-aided software engineering tools, create a file or folder or other document in the system for each of the in-bins.
When you get to a particular phase or activity, you start out by examining the in-bin, looking through it and sorting its contents for action. Some things may have become irrelevant or may have already been decided or dismissed. Ideas that once seemed spot on may now look way off target. Anything that is still valid or salient can now be worked on.
Sometimes distractions from the current thread of development go in the other direction; they concern matters that should have been taken care of earlier. In these cases, it is clearly best to attend immediately to the out-of-sequence issue in order to allow development to proceed safely and smoothly. You don't want a lot of lurking problems or loose threads bollixing up the system. When you find that some requirement is ambiguous, you go back and firm up the requirements. When you find that some architectural issues were left unresolved, you resolve them. When you find that a poor choice was made for file organization, you go back and rework the file design before moving on.
The aim, of course, is to use lots of feed-forward to reduce the amount of work-back.
From Software Development, Volume 2, #1, January 1994