Construction Principles

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.

Monolithic Construction

For our exemplified approach, the monolithic construction shall primarily illustrate two aspects:

• This construction serves its purpose exactly as it is possible according to its given shape.

• Later changes or even extensions are only feasible by means of a total reconstruction. (This restriction shall also be symbolized by the chosen material.)

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.

Modular Construction

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:

• All elements are standardized. Despite of their evident specialization they in general may be used universally.
• Elements are made of a material that can be easily worked on and thus will reduce total costs for the building. Whenever a novel type of element is used within the construction, it will be manufactured suitably.

• Significant alterations will be implemented by disassembling the construction as far as needed and reconstructing it with adapted elements.

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:

• Construction elements are used following a consistent principle, ideally without exception.

• The way the different elements have been used also represents a level of semantics (e.g. something belongs to the roof, to the wall or to a framework - in contrast to "we cannot tell exactly which role this element is playing").

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.

Entangled Construction

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 extensively:

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.

Prototype Construction

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:

• Will the housing offer enough living space for the expected demand?

• Are the windows dimensioned amply and placed wisely in order to provide sufficient light incidence?

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:

• How easily can the construction be changed or extended subseqently? For that purpose, its technical foundation has to be transparent.

• Will the chosen construction type facilitate practical use in the planned range or are there restrictions concerning functionality and load?

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:

• Effort on stability may be reduced to the minimum necessary for practical proving.

• Functional reduction in addition will bring down construction costs.

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 prototype.

Conclusion

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.

Distinguished Assessment

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 confusing interactions.

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:

• Why is origination of a heteroxyle not prevented early enough?

• What is the best way to deal with it, if it already exists?

Origination of Heteroxyles

First of all we need criteria to reliably identify a heteroxyle. For this, we may review two of the already intrudoced illustrations:

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 complex.

• 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 should provide.

Practical Approach

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.