 |
July
2000 |
By
Dr.Thomas J Mowbray |
Deadly sins are mistakes in software
development that result in failed projects, cost
overruns, schedule slips, and unfulfilled business
needs. Deadly sins are pervasive: one third of
all software projects are canceled and five out
of six software projects are unsuccessful.1 Unfortunately,
object technology has not changed this overall
prognosis. In fact, each new technology wave (such
as client-server) tends to increase software risk
and the tendency to commit deadly sins.
Experts such as Strikeleather,
Booch, Shaw,
and others agree: software architecture is perhaps
the most significant factor in software system
success or failure. There are some interesting
and unique deadly sins associated with object-oriented
(OO) software architectures.
The seven deadly sins of OO architecture
are depicted as cemetery. Among these, there are
two unpardonable sins:
the sin of haste which leads
to poor architecture quality,
and the sin of avarice which
leads to excessive architecture complexity.
Once these particular mistakes
are committed system-wide, they may be impossible
to remediate. The other deadly sins are closely
related to these unpardonable sins, as explained
below.
1. The Sin
of Haste
Hasty decisions lead to compromises
in architecture 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
estimates. As successive project deadlines are
missed, anything that appears to work is considered
acceptable, regardless of quality. In this environment,
long term architectural benefits are sacrificed
for expedience.
Quality OO architecture is the
product of careful study, decision-making, and
experimentation. At a minimum, the OO architecture
process includes farming of requirements, architecture
mining, and hands-on experience.5 Ideally, OO
architecture comprises a set of high-quality design
decisions that provide benefits throughout the
lifecycle of the system
. Significant domain experience
for the architect is essential for an OO architecture
to be competently defined and defended. With appropriate
domain experience and design patterns, quality
OO architectures can be defined rapidly.6 However,
it is always a mistake to make OO architecture
decisions hastily.
2. The
Sin of Apathy Apathy
about OO architecture leads
to a lack of partitioning. A key aspect of OO
architecture is proper partitioning. For example,
OO 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.5 The stable design
remains with the system throughout its lifecycle,
as individual software modules are modified, replaced,
and added. Replaceable design details are best
allocated to profiles, vertical specialization,
and metadata.6
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.5
3. The Sin
of Narrow-Mindedness
One of the key outcomes of architecture
partitioning is the identification of metadata.
Metadata is self-descriptive information in an
software system that enables the system to change
dynamically. Many object-oriented systems are
built with filely no metadata, a deadly sin. 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.6
4. The
Sin of Sloth
Distributed object technology
enables application developers to define system-level
interfaces quickly using the ISO Interface Definition
Language (ISO IDL).5 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 this sin is more commonplace
in small-scale OO projects, the habit of frequent
interface change is difficult to overcome. The
more interfaces change, the more the interface
semantics becomes unclear to developers. Ultimately
developers and maintainers spend more than half
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 only modified
infrequently. Stable interfaces enable parallel
development, effective documentation, and reduced
software obsolescence.
5. The
Sin of Avarice
The second set of deadly sins
is organized around the sin of avarice: lack of
abstraction. Architectural avarice means the modeling
of excessive details. This 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.
6. The Sin
of Ignorance
The sin of ignorance (implementation
dependency) often occurs in the migration of applications
to distributed architectures. In ignorance, one
assumes that system-level interfaces can be extracted
from fine-grain definitions of existing application
objects. For example, when an IDL interface is
reversed 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
supporting the same interface, then the interface
is implementation dependent. Every client or object
using this interface will be dependent upon unique
implementation details. When this occurs repeatedly
on a system-wide scale, a brittle system is created.5
This sin is also evident when vendor-proprietary
interfaces are used without proper layering and
wrapping for isolation.6
7. The
Sin of 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.5
Often, architects unnecessarily
invent new designs when knowledge from pre-existing
systems, products, and standards could be readily
applied through architecture mining.6
Re-invention 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.
Concluding
Remarks
The "seven deadly sins" is a
popular motif that has been used successfully
to identify ineffective practices. In the OO architecture
context, the key sins are haste and avarice.
Haste leads to a lack of architecture
quality. Without a quality architecture the system
will be expensive to maintain and extend.
Avarice leads to too many architectural
details (i.e. excessive complexity). Management
of complexity is a key role of architecture. With
excessive complexity, software costs and project
schedules are easily overrun.
The practice of these deadly
sins can lead to software project failures and
many other consequences due to deficiencies in
OO architecture.
|