A comment on a comment to Eberhard Wolff's recent episode 159 of Software-Architektur im Stream - Big Ball of Mud. This is a translation of this article, which was originally published in german language.
While the pioneers of computer science had to program computer systems close to the infrastructure, as technology progressed and thanks to the tireless work of people like Brooks, Buschmann and Booch, we found the way from the microscopic to the macroscopic.
However, if you read the Mythical Man Month [📖MMM] today and smile about the technology that was available at the time, you will quickly be thrown back to our present time, where problems regarding the organization and planning of projects persist. A raised finger suddenly calls for reflection: The problems of that time are still relevant today. Obviously, the development of technology has been much faster than that of planning, organization and realization of projects.
The motivation and knowledge of how to use templates to create objects and classes, and how to use all of our experience for cutting and assembling them into abstractions of a technicality, has gained momentum since the Gang of Four [📖Gof] sparked an interest in software design in a generation of programmers. But although the carpenter may be able to carve a set of window frames to match the exterior of the house, the prettiest window is of no use if nobody knows how to install it, let alone open and close it.
In our domain, such elements become problematic when their combination is supposed to be functional, and if it should resemble a maintainable structure as a whole. Experience and proven blueprints help to ensure that developers do not lose themselves in a jungle of tangled responsibilities and associations when integrating such elements.
Unfortunately, that doesn't always work out so well. When we catch ourselves breaking layers by adding a new in front of a lower-level class in a high-level class, we are one step closer to the notorious Big Ball of Mud (BBOM), which Eberhard Wolff presented and analyzed in episode 159 of his series "Software Architecture im Stream" with his usual precision.
In this episode, he also refers to the paper of Foote and Yoder, in which - more than 20 years ago - the question was asked to what extent such a Big Ball of Mud is an anti-pattern: That this negation of a structure is so often found in systems should actually lead to the conclusion that this is not an anti-pattern at all, but rather a tried and tested concept in software development, namely that of least resistance. This is characterized here by the avoidance of up-front architecture. Instead, the focus is directly on the implementation of features and functionality, also, but not exclusively, if architecture is understood as a cost factor to be avoided:
"Therefore, focus first on features and functionality, then focus on architecture and performance." [1]
A conclusion could be that we should show more understanding for the developer who chooses or must choose to develop like this. Even if such an approach prevents or dissolves a solid fundament for a software system due to the lack of best practices that are generally considered to be valuable for business. Foote and Yoder were probably also concerned with the question:
"[…] we seek not to cast blame upon those who must wallow in these mires. In part, our attitude is to ‘hate the sin, but love the sinner‘". [1]
If the Big Ball of Mud is ultimately itself a structure that contains no structure, similar to how the empty set is itself a set, then we can ex falso quodlibet accept any statement as valid if we assume that such a system has an inherent structure: And so a Big Ball of Mud is a design pattern.
But! A structure like this can be done quite easily with no experience, just as a carpenter will probably be able to stack bricks around his window without any knowledge of how to mix mortar.
Under certain circumstances, however, consciously allowing entropy to take over in a software system can also help to identify contexts and understand the technicalities in order to carve out layers and cut boundaries. In any case, Evans, Fowler and also Foote and Yoder are sure of one thing: refactoring must be done constantly in order not to lose control.
"The way to arrest entropy in software is to refactor it." [1]
However, one is also aware of the second law of thermodynamics: entropy cannot decrease, it can remain the same, or it can increase. If you want to prevent the latter, Evans advises to create a boundary around the BBOM:
"Draw a boundary around the entire mess and designate it a big ball of mud. Do not try to apply sophisticated modeling within this context. Be alert to the tendency for such systems to sprawl into other contexts." [📖DDDR, p. 38]
Foote and Yoder have a similar recommendation, which they more eloquently call "Sweeping it under the rug" in their paper:
"Therefore, if you can’t easily make a mess go away, at least cordon it off. This restricts the disorder to a fixed area, keeps it out of sight, and can set the stage for additional refactoring." [1]
It doesn't matter whether the BBOM is shoveled under the carpet or safe boundaries are created: It allows us to get selected functionality via coarse-grained interfaces out of the BBOM, and at the same time we don't allow the viscous mass to drip into our system.
Consequently, Robert C. Martin also cataloged Viscosity in the category Design Smell [📖ASD, p. 88].
My comment during the episode was that, given all of this, communicating the value of testing to management can be an added complication. I gathered from Eberhard Wolff's answer that in the scenarios he described, tests are understood to be useful a priori and are therefore part of the development process: It is mandatory to verify functionality due to the lack of architectural planning, resulting in diffuse modular boundaries.
I did not assume this implication in my comment. What I meant was: If architecture is seen as a cost factor or other conditions prevail that prevent architecture, and thus leads to a BBOM, then this can also lead to the Broken Window Effect. Hunt and Thomas have already advised: "Don't live with broken Windows." [📖PP, p. 7], and Foote and Yoder conclude from similar experiences:
"If such sprawl continues unabated, the structure of the system can become so badly compromised that it must be abandoned. As with a decaying neighborhood, a downward spiral ensues." [1]
If money and time are tight in a project and the architecture is not understood to be of value, then there is a probability that testing the software - I understand this as the kind of tests that the developer writes for verifying his code - is also seen as a negative cost factor. If the opposite is true, then the missing architecture and the resulting BBOM could be the broken window in the neighborhood, causing even more windows to be smashed. The developer who consciously does not move within the layers, but in between, feels compelled not to document his code through tests because he may fail to see any value of his work in the end. Those involved in the project are more likely to accept a broken window if there is already one next to it.
If everyone involved in the project agrees that limits and technicalities can also be recognized through unstructured, organic growth, and the system only emerges later, structures can added later: Ultimately, mud is a mass that is malleable, and the dynamic of our craftsmanship is in the name software. If the foundation does not consist of a Throw Away, then all those involved in the project should be aware that testing is required: the rationale of all those responsible prevents the first window being thrown in, and it is up to the technical experts and programmers to ensure that there won't ever be any.
References