Geeks With Blogs
James Oloo Onyango - Programming Insights Mastery of this pervasive field of programming demands a life time's effort. It cannot be bought at a lesser price!
Five sixths of all software projects are not completed in the stipulated time and within budget, of these over one third get cancelled all together. What is surprising is how little documentation there is out there on how to NOT have your software project go wrong. The first step in doing this is by identifying the Root Causes as to why  software projects fail. This, not surprisingly is one of three view points in appreciating software anti-pattterns

Root Causes are mistakes in software development that result in failed projects, cost overruns, schedule slips, and unfulfilled business needs. The root causes identified here are pervasive. The root causes are based upon the “seven deadly sins,” not surprisingly! 

I. Haste
Hasty decisions lead to compromises in software quality. Software projects are often subjected to severe schedule−related stress. At project inception, managers are pressured to trim budgets and schedules to make unrealistic targets. As successive project deadlines are missed, anything that appears to work is considered acceptable, regardless of quality. The usual victim of a slip in project delivery is testing In this environment, long−term architectural benefits are sacrificed for expedience.

II. Apathy
Apathy is not caring about solving known problems. That is not to say that all solutions are known or fully achievable, but apathy is a basic unwillingness to attempt a solution. Apathy about object−oriented architecture leads to a lack of partitioning. A key aspect of object−oriented architecture is proper partitioning. For example, object−oriented architecture partitions the system into class categories and defines their interfaces and connections. The critical partitioning decision in OO architecture is between stable reusable design and
replaceable design. The stable design remains with the system throughout its life cycle, as individual software modules are modified, replaced, and added. Replaceable design details are best allocated to profiles, vertical specializations, and metadata.
Neglecting the critical partitioning means that the core of the architecture must change in response to subsystem level changes. This means that subsystem−level changes impact all of the modules in the entire system. Thus, the sin of apathy leads to poor support for change. In addition, poorly partitioned architectures make application interoperability and reuse difficult.

III. Narrow−Mindedness
Narrow−mindedness is the refusal to practice solutions that are otherwise widely known to be effective. An example of this is the use of metadata in software systems.
Metadata is self−descriptive information in a software system that enables the system to change dynamically Many object−oriented systems are built with virtually no metadata. Without metadata, the
application software contains hard−coded bindings, relationships, and assumptions about system configuration. For example, the number of servers or clients and their locations can be made transparently variable with straightforward use of metadata services. CORBA standards include various public metadata services, such as the Naming Service, the Trader Service, and the Interface Repository.

IV. Sloth
Sloth is the “healthy sign” of a lazy developer or manager, who makes poor decisions based upon an “easy answer”. Distributed object technology enables application developers to define system−level interfaces quickly using the ISO Interface Definition Language (ISO IDL). Automatically generated interface stubs and skeletons make the task of constructing a distributed system relatively easy. The ease of creating and changing interfaces leads to the deadly sin of sloth—lack of configuration control. Although sloth is more commonplace in small−scale, object−oriented projects, the habit of frequent interface change is difficult to overcome. The more interfaces change, the more the interface semantics become unclear to developers. Ultimately, developers and maintainers spend more than half of their time performing system discovery—trying to understand how the system works. The system loses any notion of architecture long before this point is reached. Proper configuration control starts with the first phase of prototyping. Ideally, system−level interfaces are kept stable during active software development and modified only infrequently. Stable interfaces enable parallel development, effective documentation, and reduced software obsolescence.

V. Avarice
Greed can take many forms, but it leads to inappropriate software development decisions. Architectural avarice means the modeling of excessive details, which results in excessive complexity due to insufficient abstraction.Excess complexity leads to many software problems and project challenges. Overly complex systems are expensive to develop, integrate, test, document, maintain, and extend. In some cases, development steps are skipped (such as testing) in order to make up for the lost time and money. This can lead very quickly to project failure.

VI. Ignorance
Ignorance is intellectual sloth. It’s the result of failing to seek understanding. It keeps people stupid, and eventually leads to long−term software problems. The sin of ignorance (implementation dependency) often occurs in the migration of applications to distributed architectures. In ignorance, one assumes that system−level interfaces are extracted from fine−grain definitions of existing application objects. For example, when an IDL interface is reverse−engineered from existing C++ header files, implementation−dependent interfaces are created and promulgated throughout a system and its subsystems. If an object’s interface is unique and there are no other implementations that support the same interface, then the interface is implementation−dependent. Every client or object that uses this interface is dependent upon unique implementation details. When this occurs repeatedly on a systemwide scale, a brittle system is created. This sin is also evident when vendor−proprietary interfaces are used without proper layering and wrapping for isolation.

VII. Pride
The sin of pride is the not−invented−here syndrome. Object technology supports many reuse opportunities through the integration of commercial packages, freeware, and wrappered legacy applications. Often, developers unnecessarily invent new designs when knowledge from preexisting systems, products, and standards are readily applied through architecture mining. Reinvention involves many unnecessary risks and costs. New software must be designed, coded, debugged, tested, and documented. New architecture must be prototyped and evolved before it is proven to provide software benefits.

Posted on Monday, July 23, 2012 11:54 PM Software Architecture and Design | Back to top

Related Posts on Geeks With Blogs Matching Categories

Comments on this post: Software Project Failure, Root Causes and Anti-Patterns

# re: Software Project Failure, Root Causes and Anti-Patterns
Requesting Gravatar...
nice piece... I believe if developers had the time to look through this, i am sure we would meet all our deadlines.
Left by Peter Terry Arutu on Sep 11, 2012 4:52 PM

Your comment:
 (will show your gravatar)

Copyright © James Oloo Onyango | Powered by: