40 Reasons Why Software Projects Die

0.
Reinvent the Wheel
The pervasive lack of technology transfer between software projects leads to substantial reinvention. Design knowledge buried in legacy assets can be leveraged to reduce time-to-market, cost, and risk (more...)
1.
Death by Planning
Excessive planning for software projects leads to complex schedules that cause downstream problems. We explain how to plan a reasonable software development process that includes incorporating known facts and incremental replanning (more...)
2.
Intellectual Violence
Intellectual violence occurs when someone who understands a theory, technology, or buzzword uses this knowledge to intimidate others in a meeting situation (more...)
3.
Design by Committee
The classic AntiPattern from standards bodies, Design by Committee creates overly complex architectures that lack coherence. Clarification of architectural roles and improved process facilitation can refactor bad meeting processes into highly productive events (more...)
4.
The Feud
Personality conflicts between managers can dramatically affect the work environment. The employees reporting to these managers often suffer the consequences of their supervisors’ disagreements. Animosity between managers is reflected in the attitudes and actions of their employees (more...)
5.
Throw It over the Wall
Object-oriented methods, design patterns, and implementation plans intended as flexible guidelines are too often taken literally by the downstream managers and object-oriented developers. As guidelines progress through approval and publication processes, they often are attributed with unfulfilled qualities of completeness, prescriptiveness, and mandated implementation (more...)
6.
Irrational Management
Habitual indecisiveness and other bad management habits lead to de facto decisions and chronic development crises. We explain how to utilize rational management decision-making techniques to improve project resolution and for keeping managers on track (more...)
7.
Spaghetti Code
Ad hoc software structure makes it difficult to extend and optimize code. Frequent code refactoring can improve software structure, support software maintenance, and enable iterative development (more...)
8.
Cover Your Assets
Document-driven software processes often produce less-than-useful requirements and specifications because the authors evade making important decisions. In order to avoid making a mistake, the authors take a safer course and elaborate upon alternatives (more...)
9.
Fear of Success
An interesting phenomenon often occurs when people and projects are on the brink of success. Some people begin to worry obsessively about the kinds of things that can go wrong. Insecurities about professional competence come to the surface (more...)
10.
Viewgraph Engineering
On some projects, developers become stuck preparing viewgraphs and documents instead of developing software. Management never obtains the proper development tools, and engineers have no alternative but to use office automation software to produce psuedo-technical diagrams and papers (more...)
11.
Project Mismanagement
Inattention to the management of software development processes can cause directionlessness and other symptoms. Proper monitoring and control of software projects is necessary to successful development activities. Running a product development is as complex an activity as creating the project plan, and developing software is as complex as building skyscrapers, involving as many steps and processes, including checks and balances. Often, key activities are overlooked or minimized (more...)
12.
The Blob
Procedural-style design leads to one object with a lion’s share of the responsibilities, while most other objects only hold data or execute simple processes. The solution includes refactoring the design to distribute responsibilities more uniformly and isolating the effect of changes (more...)
13.
Continuous Obsolescence
Technology is changing so rapidly that developers often have trouble keeping up with current versions of software and finding combinations of product releases that work together. Given that every commercial product line evolves through new releases, the situation is becoming more difficult for developers to cope with. Finding compatible releases of products that successfully interoperate is even harder (more...)
14.
Lava Flow
Dead code and forgotten design information is frozen in an ever-changing design. This is analogous to a Lava Flow with hardening globules of rocky material. The refactored solution includes a configuration management process that eliminates dead code and evolves or refactors design toward increasing quality (more...)
15.
Ambiguous Viewpoint
Object-oriented analysis and design models are often presented without clarifying the viewpoint represented by the model. By default, OOA&D models denote an implementation viewpoint that is potentially the least useful. Mixed viewpoints don’t allow the fundamental separation of interfaces from implementation details, which is one of the primary benefits of the object-oriented paradigm (more...)
16.
Functional Decomposition
This AntiPattern is the output of experienced, nonobject-oriented developers who design and implement an application in an object-oriented language. The resulting code resembles a structural language in class structure. It can be incredibly complex as smart procedural developers devise very “clever” ways to replicate their time-tested methods in an object-oriented architecture (more...)
17.
Poltergeists
Poltergeists are classes with very limited roles and effective life cycles. They often start processes for other objects. The refactored solution includes a reallocation of responsibilities to longer-lived objects that eliminate the Poltergeists (more...)
18.
Boat Anchor
A Boat Anchor is a piece of software or hardware that serves no useful purpose on the current project. Often, the Boat Anchor is a costly acquisition, which makes the purchase even more ironic (more...)
19.
Golden Hammer
A Golden Hammer is a familiar technology or concept applied obsessively to many software problems. The solution involves expanding the knowledge of developers through education, training, and book study groups to expose developers to alternative technologies and approaches (more...)
20.
Dead End
A Dead End is reached by modifying a reusable component if the modified component is no longer maintained and supported by the supplier. When these modifications are made, the support burden transfers to the application system developers and maintainers. Improvements in the reusable component are not easily integrated, and support problems can be blamed upon the modification (more...)
21.
Input Kludge
Software that fails straightforward behavioral tests may be an example of an input kludge, which occurs when ad hoc algorithms are employed for handling program input (more...)
22.
Walking through a Minefield
Using today’s software technology is analogous to walking through a high-tech mine field. Numerous bugs are found in released software products; in fact, experts estimate that original source code contains two to five bugs per line of code (more...)
23.
Cut-and-Paste Programming
Code reused by copying source statements leads to significant maintenance problems. Alternative forms of reuse, including black-box reuse, reduce maintenance issues by having common source code, testing, and documentation (more...)
24.
Mushroom Management
In some architecture and management circles, there is an explicit policy to keep system developers isolated from the system’s end users. Requirements are passed second-hand through intermediaries, including architects, managers, or requirements analysts (more...)
25.
Autogenerated Stovepipe
This AntiPattern occurs when migrating an existing software system to a distributed infrastructure. An Autogenerated Stovepipe arises when converting the existing software interfaces to distributed interfaces. If the same design is used for distributed computing, a number of problems emerge (more...)
26.
Stovepipe Enterprise
A Stovepipe System is characterized by a software structure that inhibits change. The refactored solution describes how to abstract subsystem and components to achieve an improved system structure. The Stovepipe Enterprise AntiPattern is characterized by a lack of coordination and planning across a set of systems (more...)
27.
Stovepipe System
Subsystems are integrated in an ad hoc manner using multiple integration strategies and mechanisms, and all are integrated point to point. The integration approach for each pair of subsystems is not easily leveraged toward that of other subsystems. The Stovepipe System AntiPattern is the single-system analogy of Stovepipe Enterprise, and is concerned with how the subsystems are coordinated within a single system (more...)
28.
Jumble
When horizontal and vertical design elements are intermixed, an unstable architecture results. The intermingling of horizontal and vertical design elements limits the reusability and robustness of the architecture and the system software components (more...)
29.
Vendor Lock-In
Vendor Lock-In occurs in systems that are highly dependent upon proprietary architectures. The use of architectural isolation layers can provide independence from vendor-specific solutions (more...)
30.
Wolf Ticket
A Wolf Ticket is a product that claims openness and conformance to standards that have no enforceable meaning. The products are delivered with proprietary interfaces that may vary significantly from the published standard (more...)
31.
Architecture by Implication
Management of risk in follow-on system development is often overlooked due to overconfidence and recent system successes. A general architecture approach that is tailored to each application system can help identify unique requirements and risk areas (more...)
32.
Warm Bodies
Software projects are often staffed with programmers with widely varying skills and productivity levels. Many of these people may be assigned to meet staff size objectives (so-called “warm bodies”). Skilled programmers are essential to the success of a software project. So-called heroic programmers are exceptionally productive, but as few as 1 in 20 have this talent. They produce an order of magnitude more working software than an average programmer (more...)
33.
Swiss Army Knife
A Swiss Army Knife is an excessively complex class interface. The designer attempts to provide for all possible uses of the class. In the attempt, he or she adds a large number of interface signatures in a futile attempt to meet all possible needs (more...)
34.
The Grand Old Duke of York
Egalitarian software processes often ignore people’s talents to the detriment of the project. Programming skill does not equate to skill in defining abstractions. There appear to be two distinct groups involved in software development: abstractionists and their counterparts the implementationists (more...)
35.
Blowhard Jamboree
The opinions of so-called industry experts often influence technology decisions. Controversial reports that criticize particular technologies frequently appear in popular media and private publications. In addition to technical responsibilities, developers spend too much time answering the concerns of managers and decision makers arising from these reports (more...)
36.
Analysis Paralysis
Striving for perfection and completeness in the analysis phase often leads to project gridlock and excessive thrashing of requirements/models. The refactored solution includes a description of incremental, iterative development processes that defer detailed analysis until the knowledge is needed (more...)
37.
Corncob
Difficult people frequently obstruct and divert the software development process. Corncobs can be dealt with by addressing their agendas through various tactical, operational, and strategic organizational actions (more...)
38.
Smoke and Mirrors
Demonstration systems are important sales tools, as they are often interpreted by end users as representational of production-quality capabilities. A management team, eager for new business, sometimes (inadvertently) encourages these misperceptions and makes commitments beyond the capabilities of the organization to deliver operational technology (more...)
39.
E-mail Is Dangerous
E-mail is an important communication medium for software managers. Unfortunately, it is an inappropriate medium for many topics and sensitive communications (more...)
40.
Fire Drill
Airline pilots describe flying as “hours of boredom followed by 15 seconds of sheer terror.” Many software projects resemble this situation: “Months of boredom followed by demands for immediate delivery.” The months of boredom may include protracted requirements analysis, replanning, waiting for funding, waiting for approval, or any number of technopolitical reasons (more...)