Big Ball of Mud: Is This the Best that Agile Can Do?
Joseph Yoder, The Refactory, Inc.
Why is the gap between what we preach and what we practice so large?
Three key points:
- Mud is inevitable
- It’s not always a bad thing
- How can we make it better?
Software Architecture Group (90s) observed that many successful systems do not have a good internal structure at all.
A lot of code is hard to reuse. What is there about some systems that failed compared to systems that succeed, even when those that failed seemed better in some ways? Gabriel–Worse is Better. Release early, be quick, get things out there–these things are important. Do Big Ball of Mud (BBoM) systems have a quality that enables them to succeed? Betamax vs. VHS, Mac vs. Windows, Word vs. Framemaker.
There a lot of reasons why mud happens–external forces. Maybe if we accept it and teach it more, then we can deal with it better and help prevent it from getting too bad.
People write code–>People make mud
Three core patterns that lead to mud: Keep it working, Piecemeal growth, throwaway code. “You never got the opportunity to actually throw it away.” You’re never given time to refactor or restructure system at a later date. External forces lead to these quagmire systems.
Most reuse = copy ‘n paste. Mud may just reflect our current state of the art–there is so much that we don’t know.
Why do people build BBoM? Money. Millionaires/billionaires operate their businesses based on BBoM systems. Visual Studio is 40 million lines of code.
Agile to the rescue? Focus more on people and accept reality that software is going to change. What Agile practices help us avoid or cope with mud? Agile can make systems cleaner. It’s people working together in team efforts. It has led to acceptance or refactoring. Lots of people looking at things, support for people, more detail. Continuous attention to technical excellence, retrospectives, face-to-face conversation, working code as measure of success.
Agile principles that encourage mud: lack of upfront design, late changes to requirements, piecemeal growth.
From comment on Brian Marick blog–what value does customer get from paying back technical debt, simplifying design, cleaning code? None.
Enforcing clean code. But what do we mean by quality? It’s a degree of excellence or grade. This depends on whose perspective you are looking at systems from. Depends on one’s perspective–CTO will have different definition of quality than the architect (“The Four Winds of Making,” Dick Gabriel). In Agile, quality = working code. But if you look inside, it could be ugly and hard to maintain.
Being good enough is a quality. Does it meet minimum requirements? Many competing forces…are we desiging a system for online orders or for controlling space shuttle? They have different qualities, thus different patterns and solutions apply. Perfection is the enemy of Good Enough.
Answers to mud:
Patterns, frameworks, code design can be applied to make things better.
Make software more habitable, more livable. Can we refactor out of mud, sweep mess under the rug? Put rug at the front door? Code makeover/refactoring? Many small steps in refactoring can lead to big gains in mud busting. Tools can help with draining the swamp. Refactoring tools, testing tools, XUnit, lint tools, code critics. (Not a silver bullet.)
Testing has helped with mud-busting.
It’s a myth that Agile doesn’t support design–it’s ok to have good design. Good proven practices and patterns can help. Imitate or use proven quality techniques. You can escape from the spaghetti-code jungle. Have to commit to architecture. “SEI has done more for keeping mud out of our lives than Agile ever has.”
Maybe there are no silver bullets, but there is silver buckshot for holding off those werewolves.
Mud isn’t always bad, can be contained, can be cleaned up; our code can be more habitable. Maybe Mud is why we have Agile.