Big clump of dirt
Hi, Habr! I present to you the translation of the article " Big Ball of Mud " by Brian Foote and Joseph Yoder.
From the translator: The Big Ball of Mud article was written by Brian Foote and Joseph Yoder in the summer of 1999. She talks about the most common anti-patterns of software development, the reason for their occurrence and development. Despite the fact that more than 18 years have passed since the publication, the problems described have not disappeared, so much of the writing is still relevant today. This is the first part of the article of the three, I hope to post the rest in the near future.
In recent years, several authors [Garlan and Shaw, 1993] [Shaw, 1996] [Buschmann et al., 1996] [Meszaros, 1997] presented patterns that characterize high-level software architecture, for example, PIPELINE (pipeline) and LAYERED ARCHITECTURE ( layered architecture).
')
In an ideal world, all systems would exemplify one or more of these high-level patterns. However, in real life is not so. The architecture, which is currently dominant, has not yet been discussed. This is a BIG BALL OF MUD or LARGE CLUM OF MUD.
A BIG MUD BOWL has a carelessly designed structure, it is messy, raw, as if wound up with insulating tape and wires, tangled in a jungle spaghetti code. We all saw this code. In these systems, it is easy to find signs of unregulated growth and permanent completions. Information is distributed indiscriminately between remote elements of the system, and often all important information becomes global or duplicated. The structure of the system as a whole has never been precisely defined. If there was, then it was destroyed to such an extent that the original is no longer recognized. Programmers at least a little understanding of architecture, bypass this swamp side. And only those whom she cares little and, perhaps, those who like to patch holes in the system every day are satisfied with the work of such systems.
However, this approach is alive and well. Why is this architecture so popular? Is it as bad as it seems? Or can it serve as an intermediate station on the way to more reliable and elegant alternatives? What makes good programmers create such ugly systems? Can we avoid this? And is it necessary? How can we make these systems better?
In this article, we present the following seven patterns:
Why does the system turn into a BIG BUNCH of MUD? Sometimes big and scary systems appear because of the creation of a one-time code (THROWAWAY CODE). The one-time code is a quick, draft code that should be used only once and then thrown away. However, sometimes such code begins to live its own life, despite its undeveloped structure and poorly developed documentation or lack thereof. It works, why fix something? When a problem occurs, the fastest way to solve it is to change the working code. This eliminates the need to create a program from scratch, but over time, simple one-time programs generate a BIG KOMOK OF DIRT.
Even systems with well-written architecture risk suffering from the breakdown of the structure. Any successful system is under fire of constantly changing requirements, which gradually undermines its structure. Once pure systems are overgrown due to the gradual growth of the structure (PIECEMEAL GROWTH), and the elements of the system begin to grow out of control.
If this growth is not stopped, the structure of the system is disturbed to such an extent that it must be abandoned. As in the case of declining areas of the city, this situation is getting worse. As the understanding of the system becomes more and more difficult, its support becomes more difficult and more and more expensive. Good programmers refuse to work with such a structure. Investors withdraw their capital. And yet you can make another comparison with urban areas: there are ways to avoid and even reverse this decline. As with everything in our world, opposing entropic forces require an investment of energy. Software gentrification is no exception. One of the ways to stop entropy in software is redesign (refractoring). Adherence to periodic refactoring can protect the system from slipping into a BIG BUNCH of MUD.
Severe flooding, fire, or military action may necessitate the evacuation of residents and the restoration of the city from scratch. Most often, the changes affect individual buildings or areas, and the city itself continues to function. Once established, the KEEPING IT WORKING strategy saves the life of a city while it grows and develops again.
Systems and their constituent elements develop at different speeds. Those systems and elements that have changed faster are different from systems and elements that are slowing down. The shifted layers (SHEARING LAYERS), which are formed between them, resemble the boundaries or lines of faults and contribute to the appearance of abstract structures of the system that persist for a long time.
A simple way to begin to control the decline is to shield slum areas and put a beautiful facade around them. We call this strategy “SWEEPING IT UNDER THE RUG”. In more serious cases, it is difficult to find an alternative, so everything is being demolished and construction begins again, from scratch. When complete reconstruction (RECONSTRUCTION) is required, all that remains is to save - these are the underlying patterns.
At first glance it may seem that these are anti-patterns [Brown and others, 1998] or false patterns, but this is not so, at least in the usual sense. In fact, these approaches fill in the gaps between what we preach and what we practice. And yet, some readers doubt these patterns. Therefore, it will be wise to put all the cards on the table and declare our position. We are for good architecture.
Our main task is to help drain these swamps. Where possible, the decay of the architecture must be prevented, stopped or reversed. We will show how this can be done. In the most neglected cases, some architectural perversions will have to be removed.
At the same time, we are not going to blame those whom this bog has tightened. Our attitude to such people can be described as “we are against sin, but not a sinner. The question is even deeper. Not every backyard should have marble pillars erected. There are powerful forces that are able to unite and make the architecture recede into the background, to perform exclusively functional tasks. Especially in the early stages of software development. Opportunities and insights that allow you to develop the architecture, most often appear already in the later stages of the software life cycle.
Controlled chaos, within reasonable limits, is a natural process during construction, and this can be reconciled if everything is subsequently corrected. However, it is worth noting that complex systems can be a reliable reflection of our immature understanding of the problem. The class of systems that we can build in principle is much larger than the class of systems that we can build elegantly, at least at the very beginning. A dilapidated and tangled architecture could be a work of art for a poorly understood domain (area of ​​expertise). However, the story does not end there. When we gain experience with such domains, we will be able to send more and more energy in order to piece together the right architectural abstractions.
Patterns that we describe here will not be considered separately from each other. We have combined them into a single context, in which the other patterns described by us and other authors are also present. In particular, we compare the life cycle patterns, the prototyping phase (PROTOTYPE PHASE), the expansion phase (EXPANSIONARY PHASE) and the consolidation phase (CONSOLIDATION PHASE) described in [Foote and Opdyke, 1995] and [Coplien, 1995]; and also, compare with the software tectonics pattern (SOFTWARE TECTONICS) [Foote and Yoder, 1996] and the patterns of structure development [Roberts and Johnson, 1998].
In this chapter, we mainly talked about the disease, and all the above-mentioned patterns, we believe, can be a cure for this disease. Namely, a flexible, adaptive development process with feedback, in which design and refactoring apply to the life cycle of each artifact, component, and structure within and outside applications.
Many forces contribute to the fact that even organizations with a neat architecture are beginning to create BIG MUDS. These ubiquitous, “global” forces influence all the patterns mentioned earlier. Among such forces, we highlight the following:
Time : there will never be enough time to analyze all the long-term architectural implications of a particular design or decision. Even if the system has a good structure, architectural issues will give way to more pragmatic aspects.
One of the reasons why software architecture is often so mediocre is that it gives way to current problems, such as costs, the time from idea to implementation, the skills of a programmer. Architecture is often considered a luxury or useless excesses. Architecture is often ignored and even treated with some disdain. Of course, it is bad that such an attitude towards architecture has developed, but this can be understood. Architecture is an area that requires lengthy attention. If we want the developed product to be successful and promising, then, first of all, we need to deal with more pressing issues, which we wrote about above. And the advantages of a good architecture appear in the later stages of the life cycle, when the product is already fully formed, and reusable components appear [Foot and Opdyke, 1995].
Architecture can be viewed as Risk, which consumes resources aimed at meeting market requirements; or as an opportunity to lay the foundation for further advantage.
An immature architecture can be an advantage of a developing system, because data and functionality can take their natural place in a system that is not burdened by artificial architectural constraints. An ill-conceived, hasty architecture poses a greater danger than the absence of architecture, since unproved architectural hypotheses turn into chains that prevent architecture from developing further.
Costs : Architecture is expensive, especially when a new area is being studied. Designing the right architecture seems like a pointless luxury, if the system works that way. Investments in its development usually do not pay off immediately. In addition, it can lead to a long delay in the launch of a product on the market. Who benefits from an investment in architecture and when can we expect a return on investment? Money for fast and “raw” projects that can be immediately brought to the market is spent more readily. The money for the development and analysis of complex architecture is invested with less desire. It’s hard to recoup your architectural assets when you’ve gone bankrupt a long time ago.
Programmers who understand and know how to develop high-quality architecture, have a reputation as expensive specialists. The cost of a programmer’s work should be estimated against the costs that you incur if the costly system fails to expire and is morally obsolete. If you think that good architecture is expensive, in this case, try bad architecture.
Experience : even when a person has the time and desire to deal with architectural issues, his experience or lack of experience in a particular area can limit the architectural complexity that could be introduced into the system, especially at an early stage of system development. Some programmers succeed in an environment where they can discover and develop new abstractions, while other programmers prefer comfortable work in a more limited environment (for example, Smalltalk vs. Visual Basic). Often, the initial versions of the system are a kind of experimental tool by which programmers try to implement various elements in order to solve a specific problem. And only when problems and their solutions are found, architectural boundaries begin to appear among these embedded elements. Inexperience can take many forms. There is an absolute inexperience graduate school. A good architect may not have experience in a particular area or an expert in a particular area who knows the code perfectly, may not have experience developing architecture.
Staff turnover can damage the institutional memory of an organization and, as a dubious compromise, will have to infuse fresh blood into the organization. Changing the heads can spoil the whole dish, because each of them adds ingredients to your taste.
Skills : programmers have different skills, different professional competencies, predisposition and temperament. Some programmers are enthusiastically engaged in the search for good abstractions, while others are well versed in the wilds of complex code left by their predecessors. They vary greatly in the level of familiarity with different areas of knowledge and the ability to learn new technologies. In addition, they have different preferences in the use of languages ​​and tools.
Visibility: buildings are tangible physical structures. You can look at the building itself. You can watch the construction of the building. You can go inside and admire or criticize the design.
The user interface of the program is a public image of the program, just as its architecture is embodied in the exterior of the building. However, unlike buildings, only the people who created it can look inside the program.
The program consists of individual elements. Our perception of the program depends on how these elements are presented. Some designers prefer to use modeling languages ​​or PowerPoint images. Others like ordinary descriptions. And still others want to see the code. The way we present our architecture affects our perception of this architecture: is it good or bad, clear or tangled, elegant or dirty.
Indeed, one of the reasons for neglecting architecture is that most of it is hidden from prying eyes. If the system works and can be installed, then who cares how it looks from the inside?
Complexity : One of the reasons for the appearance of a “dirty” architecture is that software often reflects the complexity of the area in which the application is running. Brooks coined this phenomenon the term "inherent complexity" [Brooks, 1995]. In other words, the software becomes complicated and incomprehensible, because the problem itself is also not clear or, at least, not fully understood. Often, the organization of a system reflects the history of the organization that created this system (according to CONVEY Law [Coplien, 1995]). It is often difficult to reconsider existing relationships, since the basic boundaries among the elements of the system have already been established. These relations can acquire the character of the boundary of a “district”, which is observed in real cities [Brand, 1994]. There are big problems when an application needs free interaction outside these boundaries. The system turns into a tangled tangle, and even the remnants of the structure that were there initially, are beginning to collapse more and more.
Change : The architecture is a hypothesis about the future, which states that subsequent changes will be limited to the part of the project space that this architecture covers. Of course, the Universe chuckles at our attempts to make such assumptions and forecasts, throwing us something completely unexpected. The problem that we could have been told was completely excluded from our attention, but suddenly, it turned out to be very important for a new client, with whom we never thought to work. Such changes may be directly opposed to the fundamental architectural decisions taken in the light of the complete certainty that such new unforeseen circumstances will never arise. The "correct" solution can be a complete redesign of the system. But the most likely result is that the system architecture will be appropriately broken in order to fulfill the new requirements.
Scale : managing large projects is a qualitatively different problem, unlike working with small projects. This is how to bring a whole division of infantry troops into battle and command a small detachment of special forces. “Divide and conquer” is, in fact, a necessary, but insufficient solution to problems caused by scale. Alan Kay, during his speech at OOPSLA '86, noted that "good ideas do not always scale." This observation triggered a reaction from Henry Lieberman, who asked: “that is, do we have to scale bad ideas?”
the same
SLUM
SPAGHETTI CODE
Slums are squalid, indiscriminate poor neighborhoods. Perhaps everyone will agree that there is nothing good in them, but there are objective reasons conducive to the appearance of slums. What are they connected with?
Slum houses are usually built from simple, inexpensive materials using the simplest tools. Slums can be built using relatively unskilled labor. And although in the usual sense of the labor force will be "low-skilled", the construction and maintenance of buildings in slums will be a time-consuming process. Specialization is practically not required. The house is built and repaired, mostly by the residents themselves. In slums, they do not care about infrastructure, as infrastructure requires coordination of actions and capital investments, special resources, special equipment and skills. Planning or controlling the growth of slums is also practically absent. Slums appear where there is a need for housing construction, a surplus of unskilled labor and a lack of capital investment. They satisfy the immediate local need for housing, attracting available resources to solve the problem. More complex architectural approaches are a luxury that can wait.
Maintaining a slum in working order is a laborious process and requires a variety of skills. It is necessary to be able to make an improvised repair, having only available materials at hand; need to be able to repair the roof and ensure sanitary conditions. However, there is practically no qualification that can be observed in a mature economy.
Too many software systems today, from an architectural point of view, resemble such slums. Investments in tools and infrastructure are often insufficient. Tools are usually primitive, and infrastructure, such as libraries and environments, is underdeveloped. Parts of the system evolve without any verification, and the lack of infrastructure and architecture allows problems in one part of the system to deteriorate and infect adjacent parts of the system. Deadlines for the completion of the system loom on the horizon, so it seems impossible to achieve architectural elegance.
When the completion of the development of the system is approaching, actual users can start working with it for the first time.This experience can inspire changes in data format and user interface, which again negatively affects architectural solutions, although everyone thought that everything was settled with architecture. Also, as Brooks [Brooks, 1995] points out, since software is so flexible, it often bears the burden of architectural compromises at a late stage of the software / hardware documentation development cycle, precisely because of this flexibility.
This phenomenon is not unique and is found not only in software. Stewart Brand [Brand, 1994] noted that the period before the building was occupied by the first tenants is the most stressful for both architects and clients. The money runs out, and it remains to finish those parts of the building that tenants will most often encounter. During this period, it becomes obvious that some items from the list of desired things cannot be performed, and various exotic experiments will not work. Therefore, the implementation of the most important at the moment becomes a compromise solution.
Time and money is almost never enough to achieve perfection, in principle, the way it should be. In order to survive, we must do what makes our software work, as well as what will allow us to release the program on time. If the team completes the project ahead of time, then modern managers take it as a sign to give the next time less money and give less time to complete the work, or fewer people are involved in the work on the project.
You must provide high-quality software on time and fit into the budget.
Expenses: Architecture is a long-term investment. People who pay bills usually neglect this only if they do not immediately receive tangible benefits, such as writing off taxes; or if there is no extra profit or more time. However, this rarely happens. Most often, the client wants to get a product that will work for him tomorrow. As a rule, people who control and manage the development process simply do not consider the architecture as an urgent problem. If programmers know that their efforts and professionalism will be ignored, and managers still do not want to pay for good work, a vicious circle is born.
Skills: Ralph Johnson (Ralph Johnson) remarked that inevitably "on average, medium-sized companies will have average employees" One of the reasons for the popularity and success of such an approach, as a large clump of dirt may be that this approach does not require a hyperproductive virtuoso architect.
Organization : When working on large-scale projects, issues of culture, process, organizational issues, and the problem of resource allocation can take precedence over technical aspects, such as tools, languages, and architecture.
A programmer may believe that immersion in this swamp is a big question “quality of life”, but the comfort of a programmer is not the only concern of a manager, and it may contradict many other problems. A manager can perceive a quality architecture and code as an excess, which only indirectly affects the final financial result.
Therefore, the focus is first on the properties and functionality, then on the architecture and efficiency.
The situation described resembles Gabriel’s arguments “The worse the better” (Gabriel, 1991). Why does so much software turn into a BIG BUNCH of MUD, despite the best intentions and efforts of the developers? Why the tactic of "burning and landing" supersedes elegant software? Does bad architecture really crowd out good?
How does the dirty code appear to programmers who need to work with it? Data structures may be created in haste or they may not be. All parts of the application speak to each other. Any piece of important state data can become global.
There are those who interpret this situation from the point of view of an approach based on the concept of a bulletin board [Buschman, 1996], but, in fact, it is more like a hodgepodge. Where state information is classified, it can be transmitted in random order through hiding passages that bypass the original structure of the system.
The names of variables and functions can be non-informative or even misleading. The functions themselves can actively use global variables, as well as long lists of poorly defined parameters. Functions themselves are quite long and complicated and perform several unrelated tasks at once. The code multiplies. Flow control is difficult to understand and even harder to keep track of. It’s almost impossible for a programmer to figure it out. The code is simply impossible to read and decrypt. Looking at the code, we accurately determine that there is a patch on the patch and that the code was in the hands of many service technicians who could hardly understand what the consequences of their actions would be. Did we mention the documentation? What documentation?
A BIG MUDBACK can be considered an anti-pattern, as we set ourselves the task of showing how passivity of forces that negatively affect architecture can lead to a bog. However, the undeniable popularity of this pattern leads us to conclude that this is an independent pattern. This is a ubiquitous, repetitive solution to the problem of creating a working system in the context of software development. It may seem that this is the path of least resistance when the developer opposes the forces that we discussed above. And only by understanding the logic of the attractiveness of the pattern, we can direct or neutralize the forces leading to the BIG MUD OF DIRT.
One option that is notThe answer to the problem is a strict, totalitarian design from the top down. Some analysts, designers and architects have an exaggerated understanding of their abilities to do everything here and now, and then move on to implementation. This approach leads to inefficient use of resources, analytical paralysis, and the development of straitjackets.
Kent Beck described this way of creating software: Make it Work. Do the right thing. Make it fast. [Beck, 1997]. “Make it work” means that we must first concentrate on the functionality and make our product launch. “Do it right” means that we need to think about the structure of the system, only after we determine what we need to solve the problem. “Make it quick” means that we have to take care of software optimization only after we learn how to solve the problem and define an architecture that will elegantly fit into the functionality. When all these conditions are met, you can think about how to make it cheaper.
When it comes to software architecture, the rule is that the form follows the function. Here we use the word “should” not in the traditional sense of “dictating” functions. No, we mean that individual features of the architectural elements of a system often do not appear until a working code appears.
Experience in the subject area is an integral part of creating a structure. Without knowing the architectural requirements of a particular area, any attempts to create a structure will be premature, if not to say adventurous. Perhaps the only way to gain experience in the subject area at an early stage in the life cycle is to hire a specialist who has already worked in this area.
The quality of the tools used can affect the architecture of the system. If the architectural tasks of the system are probably understood by the team members, then it will be difficult to control the execution of these tasks when the system is already designed.
Finally, all engineers have different levels of skills and experience with architecture. Unfortunately, the architecture has remained undervalued for a long time, so many engineers perceive the BIG KOMOK MUD as the norm. Indeed, some engineers have particularly good skills in wading through the chaos and showing the way to others. Over time, this symbiosis between architecture and skills can change the nature of the organization, as guides to this chaos will become more valuable than architects. According to CONVEY Laws [Coplien, 1995], architects will be excluded for uselessness, and engineers who have refined their skills in working with dirty systems will be in demand. [Foote and Yoder, 1998a] went even further and said that obscure code might even have an advantage over good code, simply because it is difficult to understand and change.This advantage may extend to programmers who are able to understand such code. Such specialists may be indispensable.
Incentives that contribute to the evolution of such systems may, at times, act distortedly. Just as wordiness is easier to brevity, the creation of a complex system is easier than a simple one. Experienced programmers can create complex projects faster than other colleagues and they will succeed better than to describe and explain their project in writing. The difficulty increases until it reaches the point when an experienced programmer can no longer cope with it.
This is similar to a phenomenon called Peter’s Programming Principle. The complexity quickly increases to the level at which the programmer can still manage the code. At this moment, complexity and our ability come to an unstable balance. Blitzkrieg turns into a protracted siege. We have built the most complex system that can only work.
Such a code can become a personal sphere of interest, since the author himself hardly understands it, while others cannot even approach this code closely. As the code becomes dirty, simple code fixes become a daily responsibility. Saying how long these fixes will take is very difficult. Simple tasks turn into a real war in the trenches. Everyone gets used to slow work. Some even like it, they hide in their cozy foxhole and fix two lines of code a day.
It is interesting to note that the difference in productivity between hyper-productive and most ordinary organizations does not depend on the qualifications of employees, but on different territories. It is harder to get through the mud. Hackers in the trenches are forced every day to fight with complexity and confusion. Sometimes victory is over complexity.
« » , , .
Nevertheless, it can be said that the random, undifferentiated structure of the BIG MUD OF DIRT is one of the secret advantages, since we can directly turn to the forces acting between the two parts of the system without affecting the architectural aspirations. In a typical MUD COMKA, these aspirations will, at best, be quite modest. The random approach to architecture is characteristic of the early stages of system development, since programmers, architects, and users are still learning how to work in this area [Foote and Opdyke, 1995]. During the prototyping phase (PROTOTYPE) and extension (EXPANSION), code inheritance and a relaxed approach to encapsulation are typical. Later, when experience with the system is gained, the architectural domain becomes more distinguishable, and components of a more reliable “black box” appear. In other words,if at the beginning the system looks like a BIG BUNCH of DIRT, then that's fine, at least until you know it better.
Brian Marick (Brian Marick) first proposed the name BIG BALL OF MUD (big wad of mud) to describe this architecture. A few years ago, while speaking to a discussion group on patterns at the University of Illinois, he also noted that this is probably the dominant type of architecture. Since then, we also use this term. The name itself appeared in the 1970s to characterize the Lisp family of languages.
The architecture of the BIG Clump of MUD often emerges from one-time prototypes or a ONE-TIME CODE (THROWAWAY CODE) because the prototype is either preserved or one-time code never gets rid of (you can call it “small clumps of dirt”).
Also, this architecture may appear during the gradual maintenance and its phased growth (PIECEMEAL GROWTH) affects the structure of the mature system. As soon as the system is recognized as working, the best way to maintain growth is to use the principle “let it work” (KEEP IT WORKING). When shifted layers (SHEARING LAYERS), which appear in response to changes and further development of the system, collide with the existing structure of the system, this can lead to the development of a large clump of dirt (BIG BALL OF MUD).
Prototyping patterns and extensions [Foote and Opdyke, 1995] emphasize that the period of research and experimentation turns out to be most useful before the work on architecture begins.
However, all these actions that may affect the structure of the system must be interwoven into the consolidation phase (CONSOLIDATION PHASES) [Foote and Opdyke, 1995], during which opportunities are used to refactor the system to strengthen its structure. Extreme Programmers (Beck, 2000) also advocate continuous coding and refactoring.
[Brand, 1994] observed that buildings with large spaces, decorated with ordinary columns, have a paradoxical effect, namely, they contribute to the innovative reuse of space just because the columns limit the space created. Grand flights of architectural thought were impossible, which reduced the number of possible alternatives. Sometimes freedom from choice (FREEDOM FROM CHOICE) [Foote, 1988] is exactly what we really need.
The main enemy of any dirt is sunlight. If we subject a complex code to a thorough study, then we will be able to establish the stage of refactoring, correction and rehabilitation. Code review is one of the mechanisms that can be used to bring code to daylight.
Another extreme programming technique is pair programming [Beck, 2000]. In its pure form, pair programming means that each written line of code is added to the system by two programmers. One prints the code, and the other continuously scans the whole picture. Unlike the traditional software development method alone, with pair programming, the code is very thoroughly tested.
Code review and pair programming give the programmer something that was not in their work: the audience. Sunlight, as already mentioned, is a very powerful disinfectant. The pair practice introduces an element of activity into the programming process. The closest audience of colleagues encourages programmers to keep the code clean, understandable, and functional.
An additional advantage of pair programming is the accumulated knowledge and experience, which is quickly spread throughout the organization. In fact, this is the same advantage that sexual reproduction gives the genome.
On the contrary, if nobody looks at the code, then everyone will think that they know how to write it better than others. Programmers will respond to these anti-stimuli. Code metrics, project documentation, and other indirect signs of progress will be a major concern.
There are three ways to handle a large wad of dirt. The first is to maintain a healthy system. Constantly alternate the expansion period with the consolidation period. Refactoring and correcting code can maintain and even improve the structure of the system as it develops. The second way is to drop the system and start all over again. The reconstruction pattern (RECONSTRUCTION) is exploring a radical, but often necessary, alternative. The third way is to surrender under the pressure of chaos and become bogged down.
Since the time of the Roman architect Mark Vitruvius [Vitruvius, 20 BC], architects have followed the famous Vitruvius triad: firmitas (strength of construction), utilitas (benefit), venustas(beauty). A large clump of mud usually reflects the triumph of goodness over beauty. Strength can also be sacrificed, because an incomprehensible program nullifies the already vain attempts to maintain it. The phenomenon of swelling is observed in many large consumer software products, which once again proves that the designers decided to take up exclusively utilitarian tasks, often to the detriment of architecture and quality.
Part 2 of the article
Original article
From the translator: The Big Ball of Mud article was written by Brian Foote and Joseph Yoder in the summer of 1999. She talks about the most common anti-patterns of software development, the reason for their occurrence and development. Despite the fact that more than 18 years have passed since the publication, the problems described have not disappeared, so much of the writing is still relevant today. This is the first part of the article of the three, I hope to post the rest in the near future.
Introduction
In recent years, several authors [Garlan and Shaw, 1993] [Shaw, 1996] [Buschmann et al., 1996] [Meszaros, 1997] presented patterns that characterize high-level software architecture, for example, PIPELINE (pipeline) and LAYERED ARCHITECTURE ( layered architecture).
')
In an ideal world, all systems would exemplify one or more of these high-level patterns. However, in real life is not so. The architecture, which is currently dominant, has not yet been discussed. This is a BIG BALL OF MUD or LARGE CLUM OF MUD.
A BIG MUD BOWL has a carelessly designed structure, it is messy, raw, as if wound up with insulating tape and wires, tangled in a jungle spaghetti code. We all saw this code. In these systems, it is easy to find signs of unregulated growth and permanent completions. Information is distributed indiscriminately between remote elements of the system, and often all important information becomes global or duplicated. The structure of the system as a whole has never been precisely defined. If there was, then it was destroyed to such an extent that the original is no longer recognized. Programmers at least a little understanding of architecture, bypass this swamp side. And only those whom she cares little and, perhaps, those who like to patch holes in the system every day are satisfied with the work of such systems.
However, this approach is alive and well. Why is this architecture so popular? Is it as bad as it seems? Or can it serve as an intermediate station on the way to more reliable and elegant alternatives? What makes good programmers create such ugly systems? Can we avoid this? And is it necessary? How can we make these systems better?
In this article, we present the following seven patterns:
- BIG BALL OF MUD (BIG BUNCH OF DIRT)
- THROWAWAY CODE (SINGLE CODE)
- PIECEMEAL GROWTH (GROWTH GROWTH)
- KEEP IT WORKING (LET'S WORKING)
- SHEARING LAYERS (SLIDED LAYERS)
- SWEEPING IT UNDER THE RUG (REPLACE UNDER THE POLOVIK)
- RECONSTRUCTION (RECONSTRUCTION)
Why does the system turn into a BIG BUNCH of MUD? Sometimes big and scary systems appear because of the creation of a one-time code (THROWAWAY CODE). The one-time code is a quick, draft code that should be used only once and then thrown away. However, sometimes such code begins to live its own life, despite its undeveloped structure and poorly developed documentation or lack thereof. It works, why fix something? When a problem occurs, the fastest way to solve it is to change the working code. This eliminates the need to create a program from scratch, but over time, simple one-time programs generate a BIG KOMOK OF DIRT.
Even systems with well-written architecture risk suffering from the breakdown of the structure. Any successful system is under fire of constantly changing requirements, which gradually undermines its structure. Once pure systems are overgrown due to the gradual growth of the structure (PIECEMEAL GROWTH), and the elements of the system begin to grow out of control.
If this growth is not stopped, the structure of the system is disturbed to such an extent that it must be abandoned. As in the case of declining areas of the city, this situation is getting worse. As the understanding of the system becomes more and more difficult, its support becomes more difficult and more and more expensive. Good programmers refuse to work with such a structure. Investors withdraw their capital. And yet you can make another comparison with urban areas: there are ways to avoid and even reverse this decline. As with everything in our world, opposing entropic forces require an investment of energy. Software gentrification is no exception. One of the ways to stop entropy in software is redesign (refractoring). Adherence to periodic refactoring can protect the system from slipping into a BIG BUNCH of MUD.
Severe flooding, fire, or military action may necessitate the evacuation of residents and the restoration of the city from scratch. Most often, the changes affect individual buildings or areas, and the city itself continues to function. Once established, the KEEPING IT WORKING strategy saves the life of a city while it grows and develops again.
Systems and their constituent elements develop at different speeds. Those systems and elements that have changed faster are different from systems and elements that are slowing down. The shifted layers (SHEARING LAYERS), which are formed between them, resemble the boundaries or lines of faults and contribute to the appearance of abstract structures of the system that persist for a long time.
A simple way to begin to control the decline is to shield slum areas and put a beautiful facade around them. We call this strategy “SWEEPING IT UNDER THE RUG”. In more serious cases, it is difficult to find an alternative, so everything is being demolished and construction begins again, from scratch. When complete reconstruction (RECONSTRUCTION) is required, all that remains is to save - these are the underlying patterns.
At first glance it may seem that these are anti-patterns [Brown and others, 1998] or false patterns, but this is not so, at least in the usual sense. In fact, these approaches fill in the gaps between what we preach and what we practice. And yet, some readers doubt these patterns. Therefore, it will be wise to put all the cards on the table and declare our position. We are for good architecture.
Our main task is to help drain these swamps. Where possible, the decay of the architecture must be prevented, stopped or reversed. We will show how this can be done. In the most neglected cases, some architectural perversions will have to be removed.
At the same time, we are not going to blame those whom this bog has tightened. Our attitude to such people can be described as “we are against sin, but not a sinner. The question is even deeper. Not every backyard should have marble pillars erected. There are powerful forces that are able to unite and make the architecture recede into the background, to perform exclusively functional tasks. Especially in the early stages of software development. Opportunities and insights that allow you to develop the architecture, most often appear already in the later stages of the software life cycle.
Controlled chaos, within reasonable limits, is a natural process during construction, and this can be reconciled if everything is subsequently corrected. However, it is worth noting that complex systems can be a reliable reflection of our immature understanding of the problem. The class of systems that we can build in principle is much larger than the class of systems that we can build elegantly, at least at the very beginning. A dilapidated and tangled architecture could be a work of art for a poorly understood domain (area of ​​expertise). However, the story does not end there. When we gain experience with such domains, we will be able to send more and more energy in order to piece together the right architectural abstractions.
Patterns that we describe here will not be considered separately from each other. We have combined them into a single context, in which the other patterns described by us and other authors are also present. In particular, we compare the life cycle patterns, the prototyping phase (PROTOTYPE PHASE), the expansion phase (EXPANSIONARY PHASE) and the consolidation phase (CONSOLIDATION PHASE) described in [Foote and Opdyke, 1995] and [Coplien, 1995]; and also, compare with the software tectonics pattern (SOFTWARE TECTONICS) [Foote and Yoder, 1996] and the patterns of structure development [Roberts and Johnson, 1998].
In this chapter, we mainly talked about the disease, and all the above-mentioned patterns, we believe, can be a cure for this disease. Namely, a flexible, adaptive development process with feedback, in which design and refactoring apply to the life cycle of each artifact, component, and structure within and outside applications.
Forces
Many forces contribute to the fact that even organizations with a neat architecture are beginning to create BIG MUDS. These ubiquitous, “global” forces influence all the patterns mentioned earlier. Among such forces, we highlight the following:
Time : there will never be enough time to analyze all the long-term architectural implications of a particular design or decision. Even if the system has a good structure, architectural issues will give way to more pragmatic aspects.
One of the reasons why software architecture is often so mediocre is that it gives way to current problems, such as costs, the time from idea to implementation, the skills of a programmer. Architecture is often considered a luxury or useless excesses. Architecture is often ignored and even treated with some disdain. Of course, it is bad that such an attitude towards architecture has developed, but this can be understood. Architecture is an area that requires lengthy attention. If we want the developed product to be successful and promising, then, first of all, we need to deal with more pressing issues, which we wrote about above. And the advantages of a good architecture appear in the later stages of the life cycle, when the product is already fully formed, and reusable components appear [Foot and Opdyke, 1995].
Architecture can be viewed as Risk, which consumes resources aimed at meeting market requirements; or as an opportunity to lay the foundation for further advantage.
An immature architecture can be an advantage of a developing system, because data and functionality can take their natural place in a system that is not burdened by artificial architectural constraints. An ill-conceived, hasty architecture poses a greater danger than the absence of architecture, since unproved architectural hypotheses turn into chains that prevent architecture from developing further.
Costs : Architecture is expensive, especially when a new area is being studied. Designing the right architecture seems like a pointless luxury, if the system works that way. Investments in its development usually do not pay off immediately. In addition, it can lead to a long delay in the launch of a product on the market. Who benefits from an investment in architecture and when can we expect a return on investment? Money for fast and “raw” projects that can be immediately brought to the market is spent more readily. The money for the development and analysis of complex architecture is invested with less desire. It’s hard to recoup your architectural assets when you’ve gone bankrupt a long time ago.
Programmers who understand and know how to develop high-quality architecture, have a reputation as expensive specialists. The cost of a programmer’s work should be estimated against the costs that you incur if the costly system fails to expire and is morally obsolete. If you think that good architecture is expensive, in this case, try bad architecture.
Experience : even when a person has the time and desire to deal with architectural issues, his experience or lack of experience in a particular area can limit the architectural complexity that could be introduced into the system, especially at an early stage of system development. Some programmers succeed in an environment where they can discover and develop new abstractions, while other programmers prefer comfortable work in a more limited environment (for example, Smalltalk vs. Visual Basic). Often, the initial versions of the system are a kind of experimental tool by which programmers try to implement various elements in order to solve a specific problem. And only when problems and their solutions are found, architectural boundaries begin to appear among these embedded elements. Inexperience can take many forms. There is an absolute inexperience graduate school. A good architect may not have experience in a particular area or an expert in a particular area who knows the code perfectly, may not have experience developing architecture.
Staff turnover can damage the institutional memory of an organization and, as a dubious compromise, will have to infuse fresh blood into the organization. Changing the heads can spoil the whole dish, because each of them adds ingredients to your taste.
Skills : programmers have different skills, different professional competencies, predisposition and temperament. Some programmers are enthusiastically engaged in the search for good abstractions, while others are well versed in the wilds of complex code left by their predecessors. They vary greatly in the level of familiarity with different areas of knowledge and the ability to learn new technologies. In addition, they have different preferences in the use of languages ​​and tools.
Visibility: buildings are tangible physical structures. You can look at the building itself. You can watch the construction of the building. You can go inside and admire or criticize the design.
The user interface of the program is a public image of the program, just as its architecture is embodied in the exterior of the building. However, unlike buildings, only the people who created it can look inside the program.
The program consists of individual elements. Our perception of the program depends on how these elements are presented. Some designers prefer to use modeling languages ​​or PowerPoint images. Others like ordinary descriptions. And still others want to see the code. The way we present our architecture affects our perception of this architecture: is it good or bad, clear or tangled, elegant or dirty.
Indeed, one of the reasons for neglecting architecture is that most of it is hidden from prying eyes. If the system works and can be installed, then who cares how it looks from the inside?
Complexity : One of the reasons for the appearance of a “dirty” architecture is that software often reflects the complexity of the area in which the application is running. Brooks coined this phenomenon the term "inherent complexity" [Brooks, 1995]. In other words, the software becomes complicated and incomprehensible, because the problem itself is also not clear or, at least, not fully understood. Often, the organization of a system reflects the history of the organization that created this system (according to CONVEY Law [Coplien, 1995]). It is often difficult to reconsider existing relationships, since the basic boundaries among the elements of the system have already been established. These relations can acquire the character of the boundary of a “district”, which is observed in real cities [Brand, 1994]. There are big problems when an application needs free interaction outside these boundaries. The system turns into a tangled tangle, and even the remnants of the structure that were there initially, are beginning to collapse more and more.
Change : The architecture is a hypothesis about the future, which states that subsequent changes will be limited to the part of the project space that this architecture covers. Of course, the Universe chuckles at our attempts to make such assumptions and forecasts, throwing us something completely unexpected. The problem that we could have been told was completely excluded from our attention, but suddenly, it turned out to be very important for a new client, with whom we never thought to work. Such changes may be directly opposed to the fundamental architectural decisions taken in the light of the complete certainty that such new unforeseen circumstances will never arise. The "correct" solution can be a complete redesign of the system. But the most likely result is that the system architecture will be appropriately broken in order to fulfill the new requirements.
Scale : managing large projects is a qualitatively different problem, unlike working with small projects. This is how to bring a whole division of infantry troops into battle and command a small detachment of special forces. “Divide and conquer” is, in fact, a necessary, but insufficient solution to problems caused by scale. Alan Kay, during his speech at OOPSLA '86, noted that "good ideas do not always scale." This observation triggered a reaction from Henry Lieberman, who asked: “that is, do we have to scale bad ideas?”
BIG MUD BOWL
the same
SLUM
SPAGHETTI CODE
Slums are squalid, indiscriminate poor neighborhoods. Perhaps everyone will agree that there is nothing good in them, but there are objective reasons conducive to the appearance of slums. What are they connected with?
Slum houses are usually built from simple, inexpensive materials using the simplest tools. Slums can be built using relatively unskilled labor. And although in the usual sense of the labor force will be "low-skilled", the construction and maintenance of buildings in slums will be a time-consuming process. Specialization is practically not required. The house is built and repaired, mostly by the residents themselves. In slums, they do not care about infrastructure, as infrastructure requires coordination of actions and capital investments, special resources, special equipment and skills. Planning or controlling the growth of slums is also practically absent. Slums appear where there is a need for housing construction, a surplus of unskilled labor and a lack of capital investment. They satisfy the immediate local need for housing, attracting available resources to solve the problem. More complex architectural approaches are a luxury that can wait.
Maintaining a slum in working order is a laborious process and requires a variety of skills. It is necessary to be able to make an improvised repair, having only available materials at hand; need to be able to repair the roof and ensure sanitary conditions. However, there is practically no qualification that can be observed in a mature economy.
Too many software systems today, from an architectural point of view, resemble such slums. Investments in tools and infrastructure are often insufficient. Tools are usually primitive, and infrastructure, such as libraries and environments, is underdeveloped. Parts of the system evolve without any verification, and the lack of infrastructure and architecture allows problems in one part of the system to deteriorate and infect adjacent parts of the system. Deadlines for the completion of the system loom on the horizon, so it seems impossible to achieve architectural elegance.
When the completion of the development of the system is approaching, actual users can start working with it for the first time.This experience can inspire changes in data format and user interface, which again negatively affects architectural solutions, although everyone thought that everything was settled with architecture. Also, as Brooks [Brooks, 1995] points out, since software is so flexible, it often bears the burden of architectural compromises at a late stage of the software / hardware documentation development cycle, precisely because of this flexibility.
This phenomenon is not unique and is found not only in software. Stewart Brand [Brand, 1994] noted that the period before the building was occupied by the first tenants is the most stressful for both architects and clients. The money runs out, and it remains to finish those parts of the building that tenants will most often encounter. During this period, it becomes obvious that some items from the list of desired things cannot be performed, and various exotic experiments will not work. Therefore, the implementation of the most important at the moment becomes a compromise solution.
Time and money is almost never enough to achieve perfection, in principle, the way it should be. In order to survive, we must do what makes our software work, as well as what will allow us to release the program on time. If the team completes the project ahead of time, then modern managers take it as a sign to give the next time less money and give less time to complete the work, or fewer people are involved in the work on the project.
You must provide high-quality software on time and fit into the budget.
Expenses: Architecture is a long-term investment. People who pay bills usually neglect this only if they do not immediately receive tangible benefits, such as writing off taxes; or if there is no extra profit or more time. However, this rarely happens. Most often, the client wants to get a product that will work for him tomorrow. As a rule, people who control and manage the development process simply do not consider the architecture as an urgent problem. If programmers know that their efforts and professionalism will be ignored, and managers still do not want to pay for good work, a vicious circle is born.
Skills: Ralph Johnson (Ralph Johnson) remarked that inevitably "on average, medium-sized companies will have average employees" One of the reasons for the popularity and success of such an approach, as a large clump of dirt may be that this approach does not require a hyperproductive virtuoso architect.
Organization : When working on large-scale projects, issues of culture, process, organizational issues, and the problem of resource allocation can take precedence over technical aspects, such as tools, languages, and architecture.
A programmer may believe that immersion in this swamp is a big question “quality of life”, but the comfort of a programmer is not the only concern of a manager, and it may contradict many other problems. A manager can perceive a quality architecture and code as an excess, which only indirectly affects the final financial result.
Therefore, the focus is first on the properties and functionality, then on the architecture and efficiency.
The situation described resembles Gabriel’s arguments “The worse the better” (Gabriel, 1991). Why does so much software turn into a BIG BUNCH of MUD, despite the best intentions and efforts of the developers? Why the tactic of "burning and landing" supersedes elegant software? Does bad architecture really crowd out good?
How does the dirty code appear to programmers who need to work with it? Data structures may be created in haste or they may not be. All parts of the application speak to each other. Any piece of important state data can become global.
There are those who interpret this situation from the point of view of an approach based on the concept of a bulletin board [Buschman, 1996], but, in fact, it is more like a hodgepodge. Where state information is classified, it can be transmitted in random order through hiding passages that bypass the original structure of the system.
The names of variables and functions can be non-informative or even misleading. The functions themselves can actively use global variables, as well as long lists of poorly defined parameters. Functions themselves are quite long and complicated and perform several unrelated tasks at once. The code multiplies. Flow control is difficult to understand and even harder to keep track of. It’s almost impossible for a programmer to figure it out. The code is simply impossible to read and decrypt. Looking at the code, we accurately determine that there is a patch on the patch and that the code was in the hands of many service technicians who could hardly understand what the consequences of their actions would be. Did we mention the documentation? What documentation?
A BIG MUDBACK can be considered an anti-pattern, as we set ourselves the task of showing how passivity of forces that negatively affect architecture can lead to a bog. However, the undeniable popularity of this pattern leads us to conclude that this is an independent pattern. This is a ubiquitous, repetitive solution to the problem of creating a working system in the context of software development. It may seem that this is the path of least resistance when the developer opposes the forces that we discussed above. And only by understanding the logic of the attractiveness of the pattern, we can direct or neutralize the forces leading to the BIG MUD OF DIRT.
One option that is notThe answer to the problem is a strict, totalitarian design from the top down. Some analysts, designers and architects have an exaggerated understanding of their abilities to do everything here and now, and then move on to implementation. This approach leads to inefficient use of resources, analytical paralysis, and the development of straitjackets.
Kent Beck described this way of creating software: Make it Work. Do the right thing. Make it fast. [Beck, 1997]. “Make it work” means that we must first concentrate on the functionality and make our product launch. “Do it right” means that we need to think about the structure of the system, only after we determine what we need to solve the problem. “Make it quick” means that we have to take care of software optimization only after we learn how to solve the problem and define an architecture that will elegantly fit into the functionality. When all these conditions are met, you can think about how to make it cheaper.
When it comes to software architecture, the rule is that the form follows the function. Here we use the word “should” not in the traditional sense of “dictating” functions. No, we mean that individual features of the architectural elements of a system often do not appear until a working code appears.
Experience in the subject area is an integral part of creating a structure. Without knowing the architectural requirements of a particular area, any attempts to create a structure will be premature, if not to say adventurous. Perhaps the only way to gain experience in the subject area at an early stage in the life cycle is to hire a specialist who has already worked in this area.
The quality of the tools used can affect the architecture of the system. If the architectural tasks of the system are probably understood by the team members, then it will be difficult to control the execution of these tasks when the system is already designed.
Finally, all engineers have different levels of skills and experience with architecture. Unfortunately, the architecture has remained undervalued for a long time, so many engineers perceive the BIG KOMOK MUD as the norm. Indeed, some engineers have particularly good skills in wading through the chaos and showing the way to others. Over time, this symbiosis between architecture and skills can change the nature of the organization, as guides to this chaos will become more valuable than architects. According to CONVEY Laws [Coplien, 1995], architects will be excluded for uselessness, and engineers who have refined their skills in working with dirty systems will be in demand. [Foote and Yoder, 1998a] went even further and said that obscure code might even have an advantage over good code, simply because it is difficult to understand and change.This advantage may extend to programmers who are able to understand such code. Such specialists may be indispensable.
Incentives that contribute to the evolution of such systems may, at times, act distortedly. Just as wordiness is easier to brevity, the creation of a complex system is easier than a simple one. Experienced programmers can create complex projects faster than other colleagues and they will succeed better than to describe and explain their project in writing. The difficulty increases until it reaches the point when an experienced programmer can no longer cope with it.
This is similar to a phenomenon called Peter’s Programming Principle. The complexity quickly increases to the level at which the programmer can still manage the code. At this moment, complexity and our ability come to an unstable balance. Blitzkrieg turns into a protracted siege. We have built the most complex system that can only work.
Such a code can become a personal sphere of interest, since the author himself hardly understands it, while others cannot even approach this code closely. As the code becomes dirty, simple code fixes become a daily responsibility. Saying how long these fixes will take is very difficult. Simple tasks turn into a real war in the trenches. Everyone gets used to slow work. Some even like it, they hide in their cozy foxhole and fix two lines of code a day.
It is interesting to note that the difference in productivity between hyper-productive and most ordinary organizations does not depend on the qualifications of employees, but on different territories. It is harder to get through the mud. Hackers in the trenches are forced every day to fight with complexity and confusion. Sometimes victory is over complexity.
« » , , .
Nevertheless, it can be said that the random, undifferentiated structure of the BIG MUD OF DIRT is one of the secret advantages, since we can directly turn to the forces acting between the two parts of the system without affecting the architectural aspirations. In a typical MUD COMKA, these aspirations will, at best, be quite modest. The random approach to architecture is characteristic of the early stages of system development, since programmers, architects, and users are still learning how to work in this area [Foote and Opdyke, 1995]. During the prototyping phase (PROTOTYPE) and extension (EXPANSION), code inheritance and a relaxed approach to encapsulation are typical. Later, when experience with the system is gained, the architectural domain becomes more distinguishable, and components of a more reliable “black box” appear. In other words,if at the beginning the system looks like a BIG BUNCH of DIRT, then that's fine, at least until you know it better.
Brian Marick (Brian Marick) first proposed the name BIG BALL OF MUD (big wad of mud) to describe this architecture. A few years ago, while speaking to a discussion group on patterns at the University of Illinois, he also noted that this is probably the dominant type of architecture. Since then, we also use this term. The name itself appeared in the 1970s to characterize the Lisp family of languages.
The architecture of the BIG Clump of MUD often emerges from one-time prototypes or a ONE-TIME CODE (THROWAWAY CODE) because the prototype is either preserved or one-time code never gets rid of (you can call it “small clumps of dirt”).
Also, this architecture may appear during the gradual maintenance and its phased growth (PIECEMEAL GROWTH) affects the structure of the mature system. As soon as the system is recognized as working, the best way to maintain growth is to use the principle “let it work” (KEEP IT WORKING). When shifted layers (SHEARING LAYERS), which appear in response to changes and further development of the system, collide with the existing structure of the system, this can lead to the development of a large clump of dirt (BIG BALL OF MUD).
Prototyping patterns and extensions [Foote and Opdyke, 1995] emphasize that the period of research and experimentation turns out to be most useful before the work on architecture begins.
However, all these actions that may affect the structure of the system must be interwoven into the consolidation phase (CONSOLIDATION PHASES) [Foote and Opdyke, 1995], during which opportunities are used to refactor the system to strengthen its structure. Extreme Programmers (Beck, 2000) also advocate continuous coding and refactoring.
[Brand, 1994] observed that buildings with large spaces, decorated with ordinary columns, have a paradoxical effect, namely, they contribute to the innovative reuse of space just because the columns limit the space created. Grand flights of architectural thought were impossible, which reduced the number of possible alternatives. Sometimes freedom from choice (FREEDOM FROM CHOICE) [Foote, 1988] is exactly what we really need.
The main enemy of any dirt is sunlight. If we subject a complex code to a thorough study, then we will be able to establish the stage of refactoring, correction and rehabilitation. Code review is one of the mechanisms that can be used to bring code to daylight.
Another extreme programming technique is pair programming [Beck, 2000]. In its pure form, pair programming means that each written line of code is added to the system by two programmers. One prints the code, and the other continuously scans the whole picture. Unlike the traditional software development method alone, with pair programming, the code is very thoroughly tested.
Code review and pair programming give the programmer something that was not in their work: the audience. Sunlight, as already mentioned, is a very powerful disinfectant. The pair practice introduces an element of activity into the programming process. The closest audience of colleagues encourages programmers to keep the code clean, understandable, and functional.
An additional advantage of pair programming is the accumulated knowledge and experience, which is quickly spread throughout the organization. In fact, this is the same advantage that sexual reproduction gives the genome.
On the contrary, if nobody looks at the code, then everyone will think that they know how to write it better than others. Programmers will respond to these anti-stimuli. Code metrics, project documentation, and other indirect signs of progress will be a major concern.
There are three ways to handle a large wad of dirt. The first is to maintain a healthy system. Constantly alternate the expansion period with the consolidation period. Refactoring and correcting code can maintain and even improve the structure of the system as it develops. The second way is to drop the system and start all over again. The reconstruction pattern (RECONSTRUCTION) is exploring a radical, but often necessary, alternative. The third way is to surrender under the pressure of chaos and become bogged down.
Since the time of the Roman architect Mark Vitruvius [Vitruvius, 20 BC], architects have followed the famous Vitruvius triad: firmitas (strength of construction), utilitas (benefit), venustas(beauty). A large clump of mud usually reflects the triumph of goodness over beauty. Strength can also be sacrificed, because an incomprehensible program nullifies the already vain attempts to maintain it. The phenomenon of swelling is observed in many large consumer software products, which once again proves that the designers decided to take up exclusively utilitarian tasks, often to the detriment of architecture and quality.
Part 2 of the article
Original article
Source: https://habr.com/ru/post/351686/
All Articles