Big Ball of Mud, is a code jungle which is haphazardly structured, sprawling, sloppy and connected by duct-tape. Over the years we have been introduced to various guidelines such as SOLID, GRASP and KISS amongst age old, high cohesion and low coupling to deal with this Mud. However, the situation still remains bleak and Big Ball of Mud still seems to be the most popular way to design and architect software.
Dave Nicolette, mentioned that he recently came across a piece of code written in Java which looked like this
public Thing getThing(Integer id) {
return new Beta().getGamma().getDelta().getEpsilon().getOmega().getThing(id);
}
The code suffered from multiple code smells like
- Message Chains – the call to get the thing goes six levels deep
- Inappropriate Intimacy – client has to know about the internal structure of other classes to get to the thing
- Indecent Exposure – beta, gamma, delta etc allow indecent exposure to get to a third object
According to Dave, it seemed that
Despite the wealth of information available on the subject, it seems that the vast majority of people who write software for a living are either
(a) completely unaware of any guidelines for sound software design, or
(b) largely misunderstand the guidelines.
Likewise, FJ recalled the experience from Agile 2009 related to a session by Brian Foote and Joseph Yoder.
The reasons for mud happening were narrowed down mostly to
- Throwaway code
- Piecemeal growth
- Keep it working
- Copy / paste metastasis (faulty code is reproduced in many places and spreads)
Interestingly, as per FJ, Yoder felt that many aspects of Agile directly lead to mud. These included,
- Lack of upfront design
- Late changes to the requirements
- Late changes to the architecture
- Piecemeal growth
According to Yoder, Agile can help not as a process but because of practices like continuous attention to technical excellence, retrospectives, face to face conversations and motivated individuals. One of the tools suggested by Yoder is simple refactoring and testing whenever the software is degrading. Hence, it seems that rather than the process helping with less mud, it would ultimately be responsible developers who would have to stand up and get noticed. Unless that happens, Agile or no-Agile Big Ball of Mud might be here to stay.
As Dave put it,
Despite the emergence of development methods that encourage and facilitate well-factored code, and the growth of the Software Craftsmanship movement, the Big Ball of Mud remains the most popular design for software, including greenfield development that has the full benefit of hindsight regarding the bad design approaches of the past.