Pitfall: Thinking a new technology or methodology will solve all your IT problems

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

CATEGORIES: organizational, conceptual

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
• securing and managing those resources for the duration of the project
• 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). 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

Webster, adapted 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.