Pitfall: Asking the wrong questions
[From Pitfalls of Modern Software Engineering by Bruce F. Webster (forthcoming)]
Categories: managerial
It is a sad truism that upper management typically asks just two questions about a software development effort: “Why isn’t someone coding yet?” (known as the ‘WISCY’ question) and “When will the program ship?” These are not bad questions per se, but when they are the only questions asked, they have a tremendous distorting effect on the software development lifecycle. Software development involves so much more than just coding and shipping, so many other tasks that need to be done and done well. When those who hold purse strings for projects and power over careers focus on just these two aspects, then all the rest suffer.
This is doubly true when modern software engineering technologies and methodologies (“TOMs”) are involved, and trebly true when such TOMs being adopted by the organization for the first time. Success in such efforts depends upon thoughtful work in analysis and design, as well as an investment in quality throughout the entire lifecycle. It also depends upon have at least a core of talented developers with significant TOM-related skills and experience. And since most benefits of a new TOM come after the first few projects, these projects need to be done well.
Symptoms
Upper management focusing on just those two questions, especially in the early stages of a project.
Consequences
Coding starts much sooner than it should and for the wrong reasons. Early prototypes and experiments become the foundation of the final product. Projects drag on without stabilizing due to lack of architecture, good design, and quality engineering.
Detection
The simplest, most direct method is to work your way up the management chain, asking each manager, “What are your questions and expectations with regards to the project?” Listen carefully to the answers that you get, and don’t hesitate to ask follow-up questions.
Extraction
This is a painful one, because you have to educate upper management about the realities of software development while in the midst of a project about which they likely have unrealistic expectations (due to the TOM, particularly if it is the first time the TOM has been used). It is even more painful when you have been going along with the coding-and-ship focus, because you have to explain why you didn’t bring up all these other activities before. But that’s what you have to do: educate and explain. Almost any other course will lead ultimately to a larger disaster, though I must confess that there are project managers, directors, and VPs out there who are amazingly good at bringing crippled projects to apparent completion, then foisting them off onto others before they blow up or bog down. No one said life is fair.
Prevention
As with most pitfalls, prevention is easier-and less embarrassing-than extraction, but it can still be tough. In far too many organizations, upper management doesn’t want to know or refuses to believe the realities of software development. Still, you need to make the effort. Be honest in your project plan, set of tasks, and overall estimate. Beyond that, leave yourself some wiggle room. They may not accept it and indeed may mandate an unrealistic schedule and budget, but you will at least have gone on record with an honest estimate.
References
[Professional experience]