Software Project Anti-Patterns
Why do software development projects fail, and what can be done about it? This paper, chock full of case studies, identifies eight reasons, or anti-patterns, for unsuccessful software development and software project management. The author walks through what went wrong on numerous projects, and how things could have gone better. From “nontechnical manager leading a team of junior programmers” to “using small system methodology to build a large system” to “the agile charade” to “Rockefeller requirements,” the author combines experience, insight and wit to guide proposal teams, program managers, requirements analysts and technical leads to success.
Recognizing that the software design discipline contains stereotypical needs with common solutions, Gamma et al. formalized these into design patterns. Books and articles sprang up documenting anti-patterns—failure modes—in both software development and project management.
This paper identifies a set of anti-patterns observed by the author over a career in design, development and project management. In thinking about why software development projects fail— either cannot deliver software or cannot deliver customer satisfaction—a handful of patterns dominate the landscape.
Frederick Brooks observed that developing software is like casting a magic spell—it must be done perfectly for it to work. Software is one of the few human activities that demand perfection. The fact that these common anti-patterns span management, process and technical issues reinforces the difficulty of software development. For the project to succeed, the whole team must perform superbly, not just the coders!
This article is aimed at proposal teams, program managers, requirements analysts and technical leads in hopes of creating more successes that become referenceable projects leading to yet more successes.
The terms “Client” and “System Owner” refer to a project’s sponsor. “IT” and “the Team” refer to the IT shop, normally organizationally distinct from the sponsor.
All of the case studies actually happened, in some cases more than once.
Anti-Pattern 1: Non-Technical Manager Leading a Team of Junior Programmers
This is how the majority of failed projects fail. Here’s how it works.
1. The company bids capable managers and, to remain cost-competitive, a low-cost technical team.
2. The team divides up the work and begins working.
3. When it’s time to integrate, the pieces don’t fit together.
4. Everyone works long hours to make integration happen. But as the software comes together, it becomes increasingly clear that it doesn’t add up to the envisioned business solution.
5. The project fails to deliver, or delivers an incomplete and defect-ridden product.
The deadliest aspect of this anti-pattern is that the team is in over its head from day one, but without senior technical staff, no one suspects that there’s a problem until the team can’t deliver. After all, each developer is capable of doing his or her own piece, and that’s what management hears.
What’s lacking is a custodian of the big picture—a senior architect. Here are some examples of how this plays out in practice.
Download the full Paper, Software Project Anti-Patterns (PDF) to continue reading.