[Copyright (c) 1995, 2007 by Bruce F. Webster. All rights reserved. Last updated: [date]]
CATEGORIES: [potential categories for pitfall]
The software development process—creating software to solve a particular problem—is long and complex and has many activities and stages. The exact list will vary depending on what book or article you read but can generally be said to include the following:
becoming aware of and identifying the problem
deciding to solve the problem
deciding what resources (time, money, people, mind share, opportunity, authority) to expend solving the problem
defining the scope of the resulting project and getting it started
analyzing the problem
defining the solution
designing the solution
implementing the solution
testing the solution
verifying that the solution solves the problem in an acceptable manner
delivering the solution
modifying and refining the solution to solve new problems or fix existing ones
performing additional necessary quality assurance activities (development standards, deliverable reviews, configuration management, etc.)
Far more detail is possible here, including issues of communications, skill level, politics, and user feedback, but you get the idea. And each item has its own set of problems, challenges, and, yes, pitfalls that are quite independent of the development methodology used.
So, here’s the problem: How many of these activities will the new technology or management (“the TOM”) actually affect favorably, especially if you haven’t used the TOM before? By contrast, how much training and experience will be required to effectively apply the appropriate TOM skills in each of these areas?
Symptoms
People who say, in effect, when problems are raised, “Don’t worry, we’re using TOM; that’ll solve this problem.†I’m not sure which is more frightening: when nontechnical people say this or when technical people do. As Fred Brooks seems destined to have to prove continually, there is no “silver bullet†to slay the software development monster.
Consequences
The project slips or even fails when you discover not only that many problems are not solved by using the TOM but also that they’re made worse by doing so.
Detection
Go through the list above and test your own understanding of each of these areas and the challenges they present. Then do the same with all the other key people in the projects at all levels.
Extraction
Education of those who misunderstand. This can be difficult if they are upper-management people who have approved projects based on what turn out to be false reassurances. It can be even more difficult if these people have passed on those reassurances to others.
Prevention
Establish a process or methodology that takes you through the list above (though not necessarily in a linear fashion; see [Assuming Linear Development]). List the tasks, resources, and challenges associated with each step. Judge the impact—or lack thereof—that the TOM will have in each area. Be especially aware of the investment in training and skill development that will be required at each level as a result of adopting the TOM. And, most of all, identify all the problems that the TOM will do nothing to solve and may actually make worse.
Contributor/References
Bruce F. Webster; adapted from Pitfalls (1995).
