Pitfall: Getting on the feature release treadmill

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

CATEGORIES: political

You know the drill. By hook or crook, through long weeks and late hours and ruthless compromising, you finally deliver the project. It’s finished, it’s out the door, and you have taken a few weeks to remind yourself what real life is like. Now you have the opportunity to go back and make right all the hacks and shortcuts and ugly patches you used to get version 1.0 of the project to the customers. Besides, having done the project once, you now have a far better idea of how it should have been done in the first place. You rub your hands together and…

…you are handed a list of new features required by customers or potential customers for version 2.0 of the project, which has to ship far sooner than you would have thought. After some study, you realize that you’re not going to be able to deliver all those features within the required time frame — and even as you realize that, more features get handed down.

Your plans for cleaning up the code and the architecture are rapidly getting pushed off to version 3.0, and you really wonder whether things will be any different then.

Chances are, they won’t.

Why does this happen so often? There are several reasons, really. One may be economic necessity. Your company (division, group) may have to fund itself, which means that sales have to be sufficient to meet all expenses, including your salary and benefits. If that’s your situation, then don’t worry as much about this pitfall; architectural purity is nice, but a paycheck is better.

Another, less acceptable reason may be a short-term focus on the part of upper management. Determined to milk a current market opportunity and concerned primarily about next quarter’s results, they may not be receptive to an engineering investment that would yield more in the long run at the expense of smaller profits right now.

A third reason — not necessarily exclusive of the other two, and sometimes justified — is a suspicion on the part of upper management that engineers are more interested in doing something “cool” or “elegant” than in doing something profitable. What upper management may not understand is that elegance — architecture and code that are concise, yet clear and comprehensive, tending toward orthogonality — always pays off. Always. The only question is how soon and how much, and that is the fulcrum for the balancing act of the technical manager. Ironically, when the engineering staff is able to rapidly deliver the features requested by upper management, it is often because of a previous investment in elegance; likewise, when features take a long time to implement or bugs take a long time to fix, it’s often because of architectural gaps and past short-cuts.

Symptoms

Constantly having to push engineering work into the next planned release and not the current one.

Consequences

The cost of adding new features or extending current ones goes up, not down, over time. The program gets larger, less stable, and less cohesive. Bugs multiply, possibly causing a customer backlash.

Detection

Sit down with upper management and detail the engineering work that needs to be done. Indicate what impact this will have on the current list of desired features. See what kind of reaction you get.

Extraction

It ain’t easy. The reaction you get under Detection should give you a pretty good idea of what things will be like. There are two approaches, which should probably be used together. First, actively work with upper management and customers to determine which features are absolutely necessary and which are merely desirable — ones they could live without until the next feature release. It’s critical to talk directly with the customers, because they may not have done their own prioritizing; the list you get from management may reflect everything from essential requirements to blue-sky wishes.

Second, build engineering cleanup time into each feature so that an engineer allocated four weeks for a given feature spends, say, three weeks on the feature and one week on architecture.

Prevention

Besides using the steps described above in Extraction, you need to emphasize the need to make the proper ongoing engineering investment in order to gain the desired benefits, particularly if a new technology or methodology is involved. This means investing the time to educate management and customers, to set proper expectations, and (if possible) to run a trial project to demonstrate the process.

Contributor/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.