[From Pitfalls of Modern Software Engineering by Bruce F. Webster (forthcoming)]
Why would the use of a new technology or methodology (the “TOM”) cause managers and developers to neglect or even abandon solid software engineering practices? Because those practices are under pressure from the start. Many engineers don’t know them and aren’t willing to spend (or aren’t given) the time to learn them. Those who do know them often aren’t willing to spend (or aren’t given) the time to practice them. Technical managers, who often do understand such techniques, find themselves caught in a vise, trapped between ever-increasing (and possibly unrealistic) demands of upper management and the productivity level of the engineers they supervise.
The introduction of a new TOM can cause a new set of problems. Upper management, having read articles about the benefits of this particular TOM, may see it as an opportunity to increase demands. Developers, already under pressure to produce, milk the benefits of the TOM for all they’re worth and may find even less incentive to focus on solid software engineering. And the technical managers in the middle have to cope with the specifics of the TOM while still fighting the software engineering battles.
Upper management expects the TOM to immediately shorten the software development lifecycle and is unwilling to allocate the necessary time and resources pilot projects. Engineers neglect common sense and best practices, feeling instead that the TOM somehow magically supersedes both. Unrealistic expectations from upper management puts pressure on the development team, resulting in even more shortcuts.
Failure to achieve expected benefits of the TOM, possibly leading to (unwarranted) rejection of the TOM for future projects. Delayed, buggy, and/or failed projects.
It’s usually not hard to detect the pressure from upper management; indeed, the problem is resisting the pressure. As for the engineering-level problems, the best detection comes from regular team meetings and project reviews to go over standard (TOM-independent) software engineering practices.
This pitfall is a hard one to get out of, because upper management needs to allocate more time and resources, and the engineers need the self-discipline and education to change how they’re doing things. The key is to educate everyone about the benefits of good software engineering — established practices, predictable schedules, and higher quality — and then work the TOM into that setting.
It is sad that there is often so much resistance to doing things right in the first place. The approach is direct: realistic scheduling, definition of engineering standards, and enforcement of engineering practices. For starters, make everyone — especially upper managemen t– reads The Mythical Man-Month by Frederick P. Brooks. Then refer to it again and again as these problems arise.
Webster, from Pitfalls of Object-Oriented Development (1995).