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
"Oh that! Well Ray and Emil (theyre no longer with the company)
wrote that routine back when Jim
(who left last month) was trying a work around for Irenes input processing code
(shes in another
department now, too). I dont think its used anywhere now, but Im not
really sure. Irene didnt really
document it very clearly, so we figured we just leave well enough alone for now
After all, the bloomin
thing works doesnt it?!"
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
eventually support the standard we were working on. It was also a research-originated
system and was
As we delved into it, we interviewed many of the developers concerning certain components
massive pages of code printed out for us. Over and over again we got the same answer,
"I dont 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
currently working on it. Furthermore, as we analyzed it, we learned that the questionable
served no purpose in the current system, rather it was mostly there from previous attempts
approached by long-gone developers. The current staff, while very bright, was loath to
modify or delete
code that they didnt write or didnt 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
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
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
which no one can remember much if anything about. This is the result of earlier (perhaps
developmental times while in a research mode where developers tried out several ways of
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
related to the overall system. In fact, these flows are often so complicated looking and
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 "doesnt really cause any harm,
and might actually be critical,
and we just dont 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
This AntiPattern is, however, incredibly common in innovative design shops where proof of
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
Undocumented complex, important-looking functions, classes
or segments which dont clearly relate toe the system
Very loose "evolving" system architecture.
Whole blocks of commented-out code with no explanation or
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
As the flows compound and harden, it rapidly becomes
impossible to document the code or understand its architecture
enough to make improvements.
R&D code placed into production without thought toward
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
Lack or architecture, or non-architecture driven development.
This is especially prevalent with highly transient development
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. "Whos going to look in "all those files," just
link em in!"
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
configuration management process that ensures architectural compliance, and accommodates
creep (changing requirements). If architectural consideration is short-changed up front,
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
the software interfaces defining the systems integration solution. Management can postpone
until a clear architecture has been defined and disseminated to developers. Defining the
require one or more system discovery activities. System discovery is required to locate
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
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
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
defined, and clearly documented. Investment up-front in quality software interfaces can
dividends in the long-run compared to the cost of jack-hammering away hardened globules of
Tools such as the Source-Code Control System (SCCS) assist in configuration management.
bundled with most Unix environments and provides a basic capability to record histories of
In todays competitive world, it is often desirable to minimize the
time delay between R&D and
production. In many industries this is critical to a companys survival. Where this
is the case, inoculation
against lava flow can sometimes be found in a customized CM process that puts certain
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
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
This approach can be facilitated by periodic mapping of a prototyping system into an
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
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
While this initial investment will not show concrete results, it is certainly a good