|
The Lava Flow of obsolete technologies and forgotten extensions, leaves hardened
globules of dead code in its wake.
AntiPattern Name: Lava Flow
Also Known As: Dead Code
Most Frequent Scale: Application
Refactored Solution Name: Architectural Configuration Management
Refactored Solution Type: Process
Root Causes: Avarice, Greed, Sloth
Unbalanced Forces: Management of Functionality, Performance, Complexity
Anecdotal Evidence
"Oh that! Well Ray and Emil (they’re no longer with the company)
wrote that routine back when Jim
(who left last month) was trying a work around for Irene’s input processing code
(she’s in another
department now, too). I don’t think it’s used anywhere now, but I’m not
really sure. Irene didn’t really
document it very clearly, so we figured we just leave well enough alone for now…
After all, the bloomin’
thing works doesn’t it?!"
Background
In a data mining expedition, the authors were looking for insight into
developing a standard interface for a
particular kind of system. The system we were mining was very similar to those we hoped
would
eventually support the standard we were working on. It was also a research-originated
system and was
highly complex.
As we delved into it, we interviewed many of the developers concerning certain components
of the
massive pages of code printed out for us. Over and over again we got the same answer,
"I don’t know
what that class is for, it was written before I got here." We gradually realized that
between 30 and 50%
of the actual code comprising this complex system was not understood or documented by any
one
currently working on it. Furthermore, as we analyzed it, we learned that the questionable
code really
served no purpose in the current system, rather it was mostly there from previous attempts
or
approached by long-gone developers. The current staff, while very bright, was loath to
modify or delete
code that they didn’t write or didn’t know what it did for fear of breaking
something and not knowing
why or how to fix it.
At this point, we began referring to these blobs of code as "hardened lava",
referring to the fluid nature in
which they originated as compared to the basalt-like hardness and difficulty in removing
it once it had
solidified. Suddenly, it dawned on both of us that we had identified a potential
AntiPattern.
Nearly a year later, and after several more data mining expeditions, and interface design
efforts, we had
encountered the same pattern so frequently that we were routinely referring to Lava Flow
throughout the
department.
General Form
Typical Lava Flow source code listing
The Lava Flow AntiPattern is commonly found in systems that originated as
research but ended up in
production. It is characterized by the lava-like "flows" of previous
developmental versions strewn about
the code landscape, but now hardened into a basalt-like, immovable, generally useless mass
of code
which no one can remember much if anything about. This is the result of earlier (perhaps
Jurassic)
developmental times while in a research mode where developers tried out several ways of
accomplishing
things, typically in a rush to deliver some kind of demonstration, and therefore casting
sound design to the
winds and sacrificing documentation.
The result is several fragments of code, wayward variables classes and procedures that are
not clearly
related to the overall system. In fact, these flows are often so complicated looking and
spaghetti-like that
they seem important but no one can really explain what they do or why they exist.
Sometimes, an old
gray-haired hermit like developer can remember certain details, but everyone has decided
to "leave well
enough alone" since they code in question "doesn’t really cause any harm,
and might actually be critical,
and we just don’t have time to mess with it."
"Architecture is the art of how to waste space".
-- Phillip Johnson
While it can be fun to dissect these flows and study their anthropology,
there is usually not time in the
schedule for such meanderings. Instead, we take the expedient route and neatly work around
them.
This AntiPattern is, however, incredibly common in innovative design shops where proof of
concept or
prototype code rapidly moves into production. It is poor design, for several key reasons:
 | The Lava Flows are expensive to analyze, verify and test. All
such effort is expended entirely in vain and is an absolute waste.
In practice verification and test are rarely possible.
|
| The Lava flow code can be expensive to load into memory,
wasting important resources and impacting performance.
|
| As with many AntiPatterns, you lose many of the inherent
advantages of an OO design, in this case, you lose the ability to
leverage modularization and reuse without further proliferating
the lava flow blobs
|
Symptoms and Consequences
| Frequent unjustifiable variables and code fragments in the
system.
|
| Undocumented complex, important-looking functions, classes
or segments which don’t clearly relate toe the system
Architecture.
|
| Very loose "evolving" system architecture.
|
| Whole blocks of commented-out code with no explanation or
documentation.
|
| Lots of "in flux" or "to be replaced" code areas.
|
| Unused (dead) code, just left in. Unused, inexplicable or obsolete
interfaces in header files.
|
| If existing lava flow code is not removed, it can continue to
proliferate as code is reused in other areas.
|
| If the process that leads to lava flow is not checked, there can
be a geometric growth as succeeding developers, to rushed or
intimidated to analyze the original flows, continue to produce
new, secondary flows as they try to "work around the original
ones.
|
| As the flows compound and harden, it rapidly becomes
impossible to document the code or understand its architecture
enough to make improvements.
|
Typical Causes
| R&D code placed into production without thought toward
Configuration Management.
|
| Uncontrolled distribution of unfinished code. Implementation of
several trial approaches toward implementing some functionality.
|
| Single developer (lone wolf) written code.
|
| Lack of configuration management or compliance with process
management policies
|
| Lack or architecture, or non-architecture driven development.
This is especially prevalent with highly transient development
teams.
|
| Iterative Development Process - Often the goals of the
software project are unclear or change repeatedly. To cope with
the changes, the project must do rework, backtracking, and
prototype development efforts. In response to a demonstration
deadlines, there is a tendency to make hasty changes to code
on-the-fly to deal with immediate problems. The code is never
cleaned up, leaving architectural consideration and
documentation postponed indefinitely.
|
| Architectural Scars. Sometimes architectural commitments are
made during requirements analysis, only to be discovered not to
work after some amount of development. The system
architecture may be reconfigured, but these in-line mistakes are
seldom removed. It may not even be feasible to commented out
unnecessary code, especially in modern development
environments where hundreds of individual files comprise the
code of a system. "Who’s going to look in "all those files," just
link em in!"
|
Refactored Solution
There is only one sure-fire way to prevent the Lava Flow AntiPattern. That
is by ensuring that sound
architecture precedes production code development. This architecture must be backed up by
a
configuration management process that ensures architectural compliance, and accommodates
mission
creep (changing requirements). If architectural consideration is short-changed up front,
code is
developed that is ultimately not a part of the target architecture, and therefore
redundant or dead code.
Over time, dead code becomes problematic for analysis, testing and revision.
In cases where Lava Flow exists already, the cure can be painful. An important principle
is to avoid
architecture changes during active development. In particular, this applies to
computational architecture,
the software interfaces defining the systems integration solution. Management can postpone
development
until a clear architecture has been defined and disseminated to developers. Defining the
architecture may
require one or more system discovery activities. System discovery is required to locate
the components
that are really used and necessary to the system. The system discovery also identifies
those lines of code
that can be safely deleted. This activity is tedious; it can require the investigative
skills of an experienced
detective.
As suspected dead code is eliminated bugs will be introduced. When this happens, resist
the urge to
immediately fix the symptoms without fully understanding the cause of the error. Study the
dependencies.
This will help you to better define the target architecture.
To avoid Lava Flow, it is important to establish system-level software interfaces that are
stable, well
defined, and clearly documented. Investment up-front in quality software interfaces can
produce big
dividends in the long-run compared to the cost of jack-hammering away hardened globules of
lava flow
code.
Tools such as the Source-Code Control System (SCCS) assist in configuration management.
SCCS is
bundled with most Unix environments and provides a basic capability to record histories of
updates to
configuration-controlled files.
Related Solutions
In today’s competitive world, it is often desirable to minimize the
time delay between R&D and
production. In many industries this is critical to a company’s survival. Where this
is the case, inoculation
against lava flow can sometimes be found in a customized CM process that puts certain
limiting controls
in place at the prototyping stage, sort of like "hooks" into a real
production-class development without
the full restraining impact on the experimental nature of R&D. Where possible,
automation can play a big
role hear, but the key is in customizing a quasi CM process that can readily be scaled
into a full-blown
CM control system once the product moves into a production environment. The issue here is
really one
of balance between the costs of CM in hampering the "creative process" and the
cost of rapidly gaining
CM control of the development once that "creative process" has birthed something
useful and
marketable.
This approach can be facilitated by periodic mapping of a prototyping system into an
updated system
architecture, including limited, but standardized in line documentation of the code.
Applicability to Other Viewpoints and Scales
The architectural viewpoint plays a key role in initially preventing lava
flows.
Managers can also play a role in early identification of lava flows or the circumstances
that can lead to
lava flows. These managers must also have the authority to put the brakes on when lava
flow is first
identified, and then taking corrective measures.
As with most AntiPatterns, prevention is always cheaper than correction, so up front
investment in good
architecture and team education can typically insure a project against this and most other
AntiPatterns.
While this initial investment will not show concrete results, it is certainly a good
investment.
|
