In all technical disciplines, the ease of implementing a planned construction strongly
depends on the quality
of the chosen design. Physical limits for constructions are of smaller importance
for software development compared to other fields like
construction engineering, for instance. Thus, single infringements of rules for good
design normally will not affect the result immediately.
From a long-term point of view, however, problems will add up.
The following sections of this page contain our considerations on this subject along
with graphical exemplifications.
For keeping it short, as a start we will not specify the granularity of construction
we are talking about. The necessary
refinement will follow in our final conclusion.
For our exemplified approach, the monolithic construction shall primarily illustrate
When looking at the example drawing, it immediately strikes how difficult it would
be to change the door position
by hindsight, for instance. In some narrow confined application cases there indeed
may be no need for changes,
and under such circumstances a monolithic approach will also be reasonable, because
giving up variability saves effort.
In case it is not exactly known, though, how much the requirements on a planned construction
will change over time,
a modular construction is to be preferred instead.
Substantially more flexibility than the introduced monolith can be expected by a construction
consisting of modular elements.
The example given below shall illustrate the following aspects:
In the presented example the elements are differing dependent of their particular
function (roof, walls, framework).
Ideally they anyway will keep a certain degree of independency: Roof shelves in principle
could also be used in different
locations, as well as the framework elements for the door and the windows.
Important indicators for rating a construction to be a success are - amongst others
- the following:
Which advantages in general will result from a successful construction is most visible
when bringing home a counterexample
like the entangled construction in the following section.
In the given context here it will not be of any advantage if everything is linked
and entangled, but rather a problem:
Due to the strong interdependency between most elements of the construction, even
small changes will make a large impact.
And, to make matters worse: Merely by an analytical approach, thus without checking
it out, one can hardly state how strong each
element is interacting with others. Thus it will be harder to schedule the implementation
of new requirements.
Based on the term "monolith" (monos = single, lithos = stone) we introduce the term
"heteroxyle" for a construction like the one at hand.
Such not only consists of a single element, but instead of several different ones
("heteros"), and it is not made of stone, but of wood ("xylon").
In software development practise, heteroxyles will occur much more often than expected.
They often originate from a casual draft that
turned out to be surprisingly successful. Instead of taking such a spontaneous approach
as base for developing a regular, solid
design, one is mislead by the illusion of being already successful and abstains from
a thorough reconstruction -
probably for fear of abandoning something that is already working.
The more a heteroxyle has already been worked on, the harder it is to get rid of it
later. In practise you will only rarely find
heteroxyles in the rough, but rather rectified ones that already have been maintained
As opposed to the example before, the current outline comes with all striking protrusions
removed. Furthermore, the left and right
corner of the housing have been furnished with prominent stakes, and in the area of
the roof some of the most bulky elements
have been replaced by small ones.
Even though acknowledging a minimal development to a construction like this, it still
will remain problematic due to several reasons:
- The changes performed most likely were causing large costs. Nobody would call it a
technological breakthrough, however.
Expenses for future changes will still be rising.
- Interactions between elements remain complex and hardly predictable.
Meanings of particular element compounds still lack clarity: Which elements are representing
what exactly? If you wanted to, for example,
widen the door subsequently, you would have to determine costly, which elements are
considered to belong to the door area -
because the role of a specific element cannot be derived from the construction itself.
Despite of its weak points, a heteroxyle is more flexible than a monolith and thus
can be changed or extended more easily - at least in principle.
In practise, even small modifications will impact the stability of the whole construction.
Thus, every heteroxyle-style component
stands for an omnipresent risk for the whole software system it is embedded in:
Much like the costs of changes, also the the impacts of changes on the whole system
will be unpredictable.
What exactly shall be built in order to yield the expected benefit? This challenge
also exisits for a modular construction,
because it has to be decided in advance, which types of elements shall be used.
For being able to estimate the benefit of a planned development already before it
is finally implemented, in most cases
it is reasonable to start with a prototype.
The idea behind creating a prototype is to save constructional effort by selective
simplification, compared to the final implementation.
Nonetheless you are trying to produce a result that compares as direct as possible
to the actual planned construction in usability.
The pictured example for a prototype housing consists of branches that are not stable
by themselves. Thus they have been plastered with
loam, which provides stability for the whole building. As the construction is impermeable,
all appropriate questions that will arise for a prototype
of this kind can be answered with acceptable accuracy:
For a real loam building, already the chosen material and manufacturing would indicate
if the construction has to be considered as
a prototype, for example due to a lack of weathering resistance. In software development,
however, the long-term fitness of a construction
is rated - amongst other criteria - as follows:
Rating the pictured construction on base of the mentioned criteria, it would be identifiedas
a prototype, at least because of the loam
plaster hiding the wooden frame which makes the whole structure incomprehensible.
Due to the thin struts you would have to expect in general
that the bearing capacity is close to its limit. Thus you hardly can identify in advance,
which load limit actually exists, or at which
spots cut-outs could be applied without risk.
Under some aspects, a prototype construction is more similar to a monolith, under
others more to a heteroxyle, in turn.
However, any practical disadvantages of these relationships can be ignored as a prototype
is a reduced light-weight construction by intention:
In total, construction of a prototype will lead to a much lower costs than for other
constructions of similar range.
In case of any need for bigger changes afterwards it will be best to construct a new
In the previous sections we have compared different approaches for technical constructions:
Monolith, modular construction, entangled
construction, and prototype. Our considerations were driven by the question, why software
in practice so often tends to develop in
an unfavourable direction. Before answering this, we want to refine the outlined models
as much as necessary to clarify which
aspects in each case are especially important for us.
As foreshadowed at the very beginning of this article, drawbacks and benefits of the
respective approaches for constructions always
will apply only within special restrictions. Thus, there might be no objection against
a monolithic module, provided that it is
restricted to a manageable range of functionality. Finally, any expression of real-world
penomena as software will result into a
sequence of program steps reflecting a part of the requirements as direct as possible
- down to single lines of code that at least
have to be considered as monolithic. As soon as requirements are changing, exactly
those components of the system have to be replaced -
which will be trouble-free, as long as the monolithic parts are compact and free of
Similar applies to an entangled construction: Reduced to a moderate extent, it may
satisfy the given definition.
It will mutate to a heteroxyle accompanied with all resulting disadvantages not until
its crosslinking exceeds
a controllable degree.
Even the actually preferred principle of modular construction is not utile under all
condistions. In the given example above,
instead of working with specialized elements like different kind of boards for wall,
root and framework you could
think of introducing a further level of modularity and try to create the special elements
themselves from more general ones.
However, we might guess that cost-benefit-ratio in this thought experiment would be
bad compared to direct element construction:
Each additional level automatically will increase overall complexity of a construction.
Furthermore, any abstraction will only stay
comprehensible as long as it preserves a certain level of clarity. Seeing that, in
general it will be good advice to use
genericity and indirections only in cases one would also expect this in respect of
the given content.
A prototype, after all, stands for deliberately not satisfying specific parts of the
known requirements. This is admissible as long as
the prototype is not strained beyond of its initially designed extent.
First of all, this differentiation leads to the insight that there is no simple cure-all
which automatically will yield a good result
when implementing a complex design. Upon closer examination almost all approaches
seem to have their respective merits - except the
construction degenerating to a heteroxyle. Thus we can assume that heteroxyles either
originate unintentionally or even maybe are presumed
harmless or even useful. This leads to the following questions:
Origination of Heteroxyles
First of all we need criteria to reliably identify a heteroxyle. For this, we may
review two of the already intrudoced
Looking at the modular construction, we notice that its basic elements show a high
degree of elaborateness. Thus they facilitate
a precise construction, independently of what exactly the will be used for. Finally,
also the intended flexibility of the construction
results from the quality of its basic elements.
For the heteroxyle, the elaboration of its elements has been tied to a minimum by
using more or less casually available components
in the rough. In fact, the design could not be loosened from the existing (the fresh
cut down trees) which leads to a lack of
expressiveness in the construction.
One incentive for chosing the finally trappy way of reducing costs might be the thought,
working straightforward to the goal of a development
is "only for a start", and all necessary cleaning up will be handed in "later" (if
at all), when there is a mainfest result at
one's fingertips. Especially this approach will certainly not be successful:
- Draft elements of the construction may only be used in a way lacking a general concept.
This will lead into an upward spiral of costs whenever the construction gets more
Once you are forced to shift to a modular construction, after all, the whole effort
invested previously will be lost:
Elements of a heteroxyle cannot be converted smoothly into something modular, because
per se they are not compatible to anything.
At best, you may consider a heteroxyle in total as a prototype that has been evolved
much too costly.
Especially the last aspect mentioned will directly lead into an emotional trap: For
each new requirement you have to decide
whether to refactor everything instantly or instead add "one last change only" somehow.
From this point of view, of course the
costs for each further change will much longer stay far below the costs for total
refactoring - yet alone for the reason that,
for a heteroxyle that has been growing for a while, nobody can say exactly what functionality
in detail a substitute construction
What can we do as developers in order to avoid the mentioned problems or - in case
of already existing heteroxyles -
at least not making them worse? Our recommendations:
- In general, refine the awareness for what kind of construction we are working on:
A prototype, a modular construction,
a monolith or already a heteroxyle?
- After having made the decision for a modular construction, there is no way around
a solid elaboration of basic elements, even when
this will only lead to provisional results that cannot be shown temporarily.
- Point out as early as possible, if change requests for a component exceed a critical
limit. It would be misdirected ambition
when trying to control complexity by increasing hard work. Better plead for something
that makes the whole system simpler
event though new requirements are implemented.
Take responsibility to prevent bad choices. Developers may differ noticably concerning
which degree of obscurity in software they
individually will accept. In a complex project with several involved persons, this
may lead to the tendency that particularly
problematic modules will automatically be consigned to the care of developers with
high tolerance concerning obscurity.
Similar to how a heteroxyle normally arises gradually, it also can be dismantled by
and by - at least to a certain extent.
This can be achieved for example by intentional isolating especially problematic components
in the form of embedded monoliths.
Thus we can work towards transforming the whole heteroxyle into a composition of independent
monoliths and afterwards freeze
them as soon as possible. Based on the acquired knowledge of the already implemented
requirements we can then go for a
thorough redesign, if project management is already convinced to do so.