Escaping the Big Ball of Mud Talk
Earlier this year I was invited to give a talk at NDC Oslo. My chosen subject was the “the big ball of mud” where I go into a number of ideas and patterns to help keep your code base clean and free for extension. Here it is
Escaping the Big Ball of Mud - Mathew McLoughlin
from
NDC Conferences
on
Vimeo
.
Big ball of mud patterns tend to grow quietly inside a codebase, settling in through shortcuts, copy-pasted snippets, and assumptions that never quite get questioned. Over time the structure thickens, dependencies tangle, and the simple act of changing one feature risks breaking several others. Recognising this drift early is half the battle, since naming the problem makes it possible to act deliberately rather than stumble around in the dark.
Clean architecture offers a way out by encouraging clear boundaries and conversations between well-defined parts of the system. Instead of letting every module know everything about every other, components depend on abstractions and communicate through focused interfaces. This kind of separation makes code easier to test, easier to reason about, and far more welcoming to new developers who do not need to memorise the entire project before they can make a small change.
Design patterns support this shift by giving shared vocabulary to recurring problems. Patterns such as the command pattern, behavioural handlers, and well-considered exception strategies turn scattered ad-hoc solutions into something coherent. They do not dictate every line of code, but they provide scaffolding that holds the design together. Used thoughtfully, patterns reduce the cognitive load of working in the code and make intent visible at a glance.
Talks and writing about these ideas help spread the conversation beyond a single team or project. Sharing experiences of messy merges, forgotten constructors, and the long path towards cleaner code encourages others to keep refining their craft. Software is rarely finished, and treating the codebase as something to be cared for continuously is what keeps it responsive to the next idea, the next requirement, and the next generation of developers who will inherit it.
Earlier this year I was invited to give a talk at NDC Oslo. My chosen subject was the “the big ball of mud” where I go into a number of ideas and patterns to help keep your code base clean and free for extension. Here it is
Escaping the Big Ball of Mud - Mathew McLoughlin from NDC Conferences on Vimeo .
Big ball of mud patterns tend to grow quietly inside a codebase, settling in through shortcuts, copy-pasted snippets, and assumptions that never quite get questioned. Over time the structure thickens, dependencies tangle, and the simple act of changing one feature risks breaking several others. Recognising this drift early is half the battle, since naming the problem makes it possible to act deliberately rather than stumble around in the dark.
Clean architecture offers a way out by encouraging clear boundaries and conversations between well-defined parts of the system. Instead of letting every module know everything about every other, components depend on abstractions and communicate through focused interfaces. This kind of separation makes code easier to test, easier to reason about, and far more welcoming to new developers who do not need to memorise the entire project before they can make a small change.
Design patterns support this shift by giving shared vocabulary to recurring problems. Patterns such as the command pattern, behavioural handlers, and well-considered exception strategies turn scattered ad-hoc solutions into something coherent. They do not dictate every line of code, but they provide scaffolding that holds the design together. Used thoughtfully, patterns reduce the cognitive load of working in the code and make intent visible at a glance.
Talks and writing about these ideas help spread the conversation beyond a single team or project. Sharing experiences of messy merges, forgotten constructors, and the long path towards cleaner code encourages others to keep refining their craft. Software is rarely finished, and treating the codebase as something to be cared for continuously is what keeps it responsive to the next idea, the next requirement, and the next generation of developers who will inherit it.