BIG BALL OF MUD

This paper is definitely the most interesting of the papers I have read so far in this class. All the points made in the paper are very applicable to many of the projects I worked on. big ball of mud systems are unstructured, with no clear defined architecture style. It typically has many code smells like, duplicated code, spaghetti code. These systems evolve over time with no formal architecture, with various people working on it and making fixes just to keep the system running. From my experience there many reasons that impact the quality of the software: Ever changing requirements, cost and aggressive schedules are usual characteristics of many software projects. People do not have the time and the money to invest on good architectures and therefore big ball of mud are created. It is very interesting that the authors document this kind of systems. They explain why this kind of architecture is so popular. Among the forces behind theses systems are the cost of architecture and the skills of programmers. The authors explain in the patterns how the programmer maintaining the messy code should learn to understand how it evolved, what it does, and how to improve it.
I like this quote:
“Overgrown, tangled, haphazard spaghetti code is hard to comprehend, repair, or extend, and tends to grow even worse if it is not somehow brought under control”
This is such an important statement. If it is hard to understand, restructure and make changes to a system, it is important to stop the system from getting even worse. This should be done by correctly planning and structuring any new addition to the system so that the mess can be restricted to a fixed area

I have worked on a legacy system that was first developed about 30 years ago. Most of the senior members on the project started with horizontal microcode, then change the project over the years to use C and C++. The code is messy because of the thousands of patches and new functionalities that have been added over the years to keep the system running and provide new value to customers. Working in that environment I realize how many factors influence the quality of a system and how important it is to try to understand theses system as described in this paper.