Pitfall: Attempting too much, too fast, too soon

[From Pitfalls of Modern Software Engineering by Bruce F. Webster (forthcoming)]

Categories: managerial

If your organization is adopting some new technology or methodology (the “TOM”), it is likely because of wonderful claims about how it will improve your software engineering efforts: faster development time, higher quality, lower complexity, and so on. Leaving aside the likelihood of achieving such claims, these hypothetical benefits still inspire or tempt managers and developers alike to leap feet first into adopting the TOM, using it to tackle large projects with short deadlines.

The result is like crossing a swamp. The ground starts out a bit damp and the undergrowth a bit thick, but you can make good progress with your new TOM machete. As you push ahead, however, you face mud, vines, snakes, water, and alligators in ever- increasing proportions. You may choose to push ahead or to go back, but in either case the effort and cost are greater than if you had used caution before plunging in. And those above you want to know what happened to all the wonderful benefits of this TOM.

Symptoms

A project that doesn’t seem to be making much progress or one that seems ill-defined.

Consequences

Schedule slips and project failure. If initial adoption of the TOM in question (or some key variant thereof), loss of acceptance of that technology and loss of professional credibility.

Detection

Enumerate all that you hope to accomplish with this project. See how soon in the process the coding and prototyping started. Measure current status against the announced schedule and make a realistic assessment of where you are.

Extraction

This can be really tough. Once you’re in the middle of a project, you have a lot of people counting on you to deliver certain solutions by a particular date. You might be hesitant to stop everything and plan the entire development effort again. On the other hand, there is a good chance — in fact, almost a certainty — that if you have stumbled into this pitfall, your efforts to get out of it may not be fully understood or appreciated by those in authority.

Nevertheless, the best solution is to halt development and take the time to scale down the project and train developers; then you can set realistic deadlines.

Prevention

Look again at the pitfall: too much, too soon, too fast. First, start out small when using the new TOM for the first (or second or third!) time. Use well-defined, small-scale pilot projects. Or whittle down your large project into a small one on which you can build in later development cycles.

Second, take time for education, analysis, and design. Make sure that everyone involved understands the concepts, techniques, and — yes — the pitfalls of this particular TOM. Resist the temptation to start prototyping and coding immediately; go through an explicit, detailed analysis phase and take time to go through a design phase.

Third, plan for your initial TOM-based projects to take at least as long as they would if developed using traditional software engineering approaches. You may be pleasantly surprised; you almost certainly won’t have a rude awakening. After you get several projects under your belt, you’ll become more accurate at projecting development cycles.

References

Webster, from Pitfalls of Object-Oriented Development (1995).

About the Author: bfwebster

Webster is Principal and Founder at at Bruce F. Webster & Associates, as well as an Adjunct Professor for the BYU Computer Science Department. He works with organizations to help them with troubled or failed information technology (IT) projects. He has also worked in several dozen legal cases as a consultant and as a testifying expert, both in the United States and Japan. He can be reached at 303.502.4141 or at bwebster@bfwa.com.