It was back in ‘97 when Brian Foote and I first opined that: while much attention had been focused on high-level software architectural patterns, what is, in effect, the de-facto standard software architecture had seldom been discussed: the Big Ball of Mud. A Big Ball of Mud is haphazardly structured, sprawling, sloppy, duct-tape and bailing wire, spaghetti code jungle. We’ve all seen them. These systems show unmistakable signs of unregulated growth, and repeated, expedient repair. Information is shared promiscuously among distant elements of the system, often to the point where nearly all the important information becomes global or duplicated. The overall structure of the system may never have been well defined. If it was, it may have eroded beyond recognition. Programmers with a shred of architectural sensibility shun these quagmires. Only those who are unconcerned about architecture, and, perhaps, are comfortable with the inertia of the day-to-day chore of patching the holes in these failing dikes, are content to work on such systems. Somewhat to our astonishment, since our original statement, no one has ever undertaken to dispute this premise. Still, this approach endures and thrives. Why is this architecture so popular? Is it as bad as it seems, or might it serve as a way-station on the road to more enduring, elegant artifacts? What forces drive good programmers to build ugly systems? Can we avoid this? Should we? How can we make such systems better? This keynote will examine the paradoxes that underlie Big Balls of Mud, what causes them, and why they are so prominent. What Agile Practices help us avoid or cope with mud? Does Agile practices such as TDD really help minimize mud? What are we doing RIGHT? What Agile Practices contribute to the problem? Encourage mud? Is Mud really the best that Agile can do? Is Agility’s utilitarian focus on process rather than design its secret weapon, or its Achilles heel?

1. Big Balls of Mud in
Agile Development –
Can we Avoid Them?
Joseph W. Yoder
Copyright 2010 Joseph W. Yoder & The Refactory, Inc.

2. Evolved from The UIUC SAG
In the early 90‟s we were studying
objects, frameworks, components,
reusability, patterns, “good” architecture.
However, in our SAG group we often
noticed that although we talk a good
game, many successful systems do not
have a good internal structure at all.
Big Balls of Mud in Agile Development – Can we Avoid Them -- 2

3. Selfish Class
Brian and I had just published a paper
called Selfish Class which takes a code’s-
eye view of software reuse and evolution.
In contrast, our BBoM paper noted that in
reality, a lot of code was hard to (re)-use.
Big Balls of Mud in Agile Development – Can we Avoid Them -- 3

4. Why BBoM?
Why was this phenomenon so
prevalent in our industry? We
talk a good game.
We had seen where Lisp had failed,
Smalltalk was starting to fail,
Windows was winning. Why was
this? What is there about some
systems that failed compared to
systems that succeed, even when
they seemed better.
Big Balls of Mud in Agile Development – Can we Avoid Them -- 4

5. Big Ball of Mud
Alias: Shantytown, Spaghetti Code
A BIG BALL OF MUD is haphazardly
structured, sprawling, sloppy, duct-tape and bailing
wire, spaghetti code jungle.
The de-facto standard software
architecture. Why is the gap
between what we preach and
what we practice so large?
We preach we want to build high quality
systems but why are BBoMs so prevalent?
Big Balls of Mud in Agile Development – Can we Avoid Them -- 5

6. Big Ball of Mud
Big Balls of Mud in Agile Development – Can we Avoid Them -- 6

7. Worse is Better
Ideas resembles Gabriel‟s 1991
“Worse is Better”
Worse is Better is an argument to
release early and then have the
market help you design the final
product. It is taken as the first
published argument for open
source, among other things.
Do BBoM systems have a Quality?
Big Balls of Mud in Agile Development – Can we Avoid Them -- 7

8. Worse is Better (examples)
Betamax vs VHS Format
 Why did VHS win?
 Betamax was arguably a better format
Macintosh vs Windows
 Mac was easier to use
 Far superior in many ways
MS Word/Publisher vs FrameMaker
 Lot‟s of people use word
 FrameMaker is better for books
Big Balls of Mud in Agile Development – Can we Avoid Them -- 8

9. What exactly do we
mean by "Big"?
Well, for teams I consider > 10^2 big
and for code I consider > 10^5 big
Teams can write good code. Smalltalk
is an example. I've seen teams of things
written by 10^1 or 10^2 be pretty good
and definitely would not be considered
to be a BBoM.
Big Balls of Mud in Agile Development – Can we Avoid Them -- 9

10. Mud == Anti-Pattern???
In one sense Mud could be seen as an anti-pattern.
Reasons Mud Happens:
Throwaway Code, Piecemeal Growth, Keep it Working.
Similar Forces that lead to BBoM and anti-patterns.
Difference is that with BBoMs many reasons why they
happened and are even successful (and maybe even
necessary given our current state of the art).
Anti-Patterns were almost the opposite when you looked at
the book. These are counterproductive practices.
Big Balls of Mud in Agile Development – Can we Avoid Them -- 10

11. Legacy == Mud?
Big Balls of Mud in Agile Development – Can we Avoid Them -- 11

12. Legacy != Mud???
Does Legacy happen within months or a year
after the first release?
Or is legacy after the second release?
What about Muddy code that is released on the
first version? Is this a counterexample?
Is all Legacy Mud? Smalltalk???
Big Balls of Mud in Agile Development – Can we Avoid Them -- 12

13. Is Mud Normal?
Well, just read our paper....there are
"normal" reasons why it happens. Maybe
it is the best we can do right now.
If mud is such a bad thing, why do people
keep making it?
Maybe if we accept it and teach it more
then we can deal with it better and help
prevent it from getting too bad.
Big Balls of Mud in Agile Development – Can we Avoid Them -- 13

14. Question
So, why DO people build Big Balls of Mud?

15. Where Mud Comes From
Big Balls of Mud in Agile Development – Can we Avoid Them -- 15

16. Software Decay
Big Balls of Mud in Agile Development – Can we Avoid Them -- 16

17. Robber Crops
Big Balls of Mud in Agile Development – Can we Avoid Them -- 17

18. Keep it Working, Piecemeal
Growth, Throwaway Code
Big Balls of Mud in Agile Development – Can we Avoid Them -- 18

19. Copy „n‟ Paste
Big Balls of Mud in Agile Development – Can we Avoid Them -- 19

20. The Age of Sampling
Big Balls of Mud in Agile Development – Can we Avoid Them -- 20

21. Big Bucket of Glue
Big Balls of Mud in Agile Development – Can we Avoid Them -- 21

22. The Mystery of Dark Matter
Big Balls of Mud in Agile Development – Can we Avoid Them -- 22

23. They Have a Name
Big Balls of Mud in Agile Development – Can we Avoid Them -- 23

24. Agile to the Rescue???
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
…From the Agile Manifesto
Big Balls of Mud in Agile Development – Can we Avoid Them -- 24

25. Question
What Agile Practices help us avoid or cope
with mud? Does Agile practices such as
TDD really help minimize mud? What are
we doing RIGHT?
What Agile Practices contribute to the
problem? Encourage mud? So Is Mud
really the best that Agile can do?

26. Do Some Agile Principles
Encourage mud?
Lack of Upfront Design?
Late changes to the requirements
of the system?
Continuously Evolving the Architecture?
Piecemeal Growth?
Focus on Process rather than Architecture?
Working code is the measure of success!
I‟m sure there are more!!!
Big Balls of Mud in Agile Development – Can we Avoid Them -- 26

27. Can Agile Help?
Scrum, TDD, Refactoring, Regular
Feedback, Testing, More Eyes, …
Good People!
Continuous attention to technical excellence!
Retrospectives!
Face-To-Face conversation.
Motivated individuals with the environment
and support they need.
Big Balls of Mud in Agile Development – Can we Avoid Them -- 27

28. Do we really need Agile Practices
such as TDD to avoid mud?
After all, most of the early STers I know
never practiced TDD or SCRUM yet we
claim these methods helps create clean
code and avoid mud more easily. Is this
really true or are there other methods that
work as well or better at minimizing mud?
Maybe it is just good teams of people no
matter what method they use?
Big Balls of Mud in Agile Development – Can we Avoid Them -- 28

29. Question
Is Craftsmanship the Cure? Or maybe it is
the problem? Is ascribing poor code to
unhygienic habits, even malpractice, is
enough, or naive; is mud inevitable?
Does quality matter? Quality on the
outside vs. Quality on the inside? Does
quality just get in the way? Is "Clean" the
Answer? Or only part of the answer? Or
a sideshow?

30. Shoddy Workmanship
Big Balls of Mud in Agile Development – Can we Avoid Them -- 30

31. Amish Furniture
Big Balls of Mud in Agile Development – Can we Avoid Them -- 31

32. The Quality Goes In
Big Balls of Mud in Agile Development – Can we Avoid Them -- 32

33. Quality
Quality Definition: a peculiar and essential
character or nature, an inherent feature or
property, a degree of excellence or grade, a
distinguishing attribute or characteristic
Big Balls of Mud in Agile Development – Can we Avoid Them -- 33

34. Quality (Who‟s perspective)
“The Four Winds of
Artist Scientist
Making”…Gabriel
important/boring true/false
An architect might
have perspectives
Designer Engineer from an artist to a
design or an
engineer!
cool/uncool good/bad
Rich Gold "The Plenitude: Creativity, Innovation & Making Stuff
(Simplicity: Design, Technology, Business, Life)“
Triggers and Practices – Richard Gabriel http://www.dreamsongs.com
Big Balls of Mud in Agile Development – Can we Avoid Them -- 34

35. Quality by Attributes
Quality in everyday life and business,
engineering and manufacturing can be
seen as the usefulness of something.
Usually describes certain attributes.
• For example you could describe quality in
terms of performance, reliability (fault
tolerance), safety, maintainability,
reusability, etc…
Does quality on the inside
mean quality on the outside?
Big Balls of Mud in Agile Development – Can we Avoid Them -- 35

36. “Ility” Requirements
Accessibility Reliability
Compatibility Safety
Efficiency Scalability
Effectiveness Security
Extensibility Stability
Maintainability Supportability
Performance Usability
Covers things such as "constraints“, "quality attributes“,
and "quality of service requirements"
Qualities are usually described by “ilities” are often called non-functional
requirements…but quality can also focus on how well the functional
requirements are met (how to measure this?)
Big Balls of Mud in Agile Development – Can we Avoid Them -- 36

37. How can we measure?
Standards?
Is it hard to Maintain?
Is it good enough?
Does it meet the minimum requirements?
Big Balls of Mud in Agile Development – Can we Avoid Them -- 37

38. Brooklyn Bridge
John Augustus Roebling
The Brooklyn Bridge, 1883,
one of the oldest suspension
bridges in the United States, stretches
over a mile from Brooklyn to Manhattan.
On completion, it was the largest
suspension bridge in the world and the
first steel-wire suspension bridge.
Big Balls of Mud in Agile Development – Can we Avoid Them -- 38

39. Brooklyn Bridge
John Augustus Roebling
His son Washington succeeded
him, but was stricken with
caisson disease.
Manhattan side of the tower it is 10 meters
short of the bedrock...rests on sand!
Big Balls of Mud in Agile Development – Can we Avoid Them -- 39

40. Brooklyn Bridge
Over engineered. Had 6 times what it
needed which proved useful over time
What happens if we tried overdesign of our systems
(a language for printing hello world) or the same line
of code 6 times (is this 6 times more reliable?)
if (x != a) x = a; if (x != a) x = a; if (x != a) x = a;
if (x != a) x = a; if (x != a) x = a; if (x != a) x = a;
Redundant components can
make our systems more reliable
Big Balls of Mud in Agile Development – Can we Avoid Them -- 40

41. Being Good Enough
 Quality of being good enough
 Does it meet the minimum requirements
 Quality has many competing forces…are
we designing a system for online orders
or for controlling the space shuttle, they
have different qualities, thus different
patterns and solutions apply
Big Balls of Mud in Agile Development – Can we Avoid Them -- 41

42. Many Quality Patterns Written
Design Patterns
Patterns for Fault Tolerant Software
Performance Patterns
Small Memory Software Patterns
Analysis Patterns
Security Patterns
Stability Patterns
Usability Patterns
Imitate or use proven quality techniques
Big Balls of Mud in Agile Development – Can we Avoid Them -- 42

43. Implementation Patterns
Patterns about creating quality code that
communicates well, is easy to understand,
and is a pleasure to read. Book is about
patterns of “Quality” code.
But…Kent states, “…this book is built on a fragile
premise: that good code matters. I‟ve seen too
much ugly code make too much money to believe
that quality of code is either necessary or sufficient
for commercial success or widespread use.
However I still believe quality of code matters.”
Patterns assist with making code more bug free and
easier to maintain and extend.
Big Balls of Mud in Agile Development – Can we Avoid Them -- 43

44. Does quality really matter?
Is "Clean" the Answer? Or only part of the answer? Or a
sideshow? Who ever said code was supposed to be pretty?
Being clean or cleaning up certain parts of the mud might help in
the short run. However, as we've heard before, Lipstick on a
Pig and you still have a pig, or dressing it up, still doesn't get rid
of the mess inside.
But maybe we don't need to clean it all up. Is this even completely
possible for something of any size. I claim that at times you will
always have some muddy code. There are counter forces to
trying to make something too perfect. Perfection is the enemy
of Good Enough and sometimes Good enough is all we
need. No normal end-user looks into the middle of something
and says, that is it...we got beauty.
Big Balls of Mud in Agile Development – Can we Avoid Them -- 44

45. Is Craftsmanship the Cure?
Or is it the problem?
On the average, average companies get
average people (law of averages).
Is ascribing poor code to unhygienic habits,
even malpractice, is enough, or naive; is mud
inevitable?
Big Balls of Mud in Agile Development – Can we Avoid Them -- 45

46. Question
When do we gentrify, rehabilitate, or make-
over code, and when must be demolish
and/or replace it? (In other words) Is mud
reversible?
How much have patterns, frameworks,
components, even objects helped with
mud?

47. Total Code Makeover
Can we just Refactor out of Mud?
Big Balls of Mud in Agile Development – Can we Avoid Them -- 47

48. Code Make Over?
Refactoring can help reverse some mud. The
tradeoff is cost and time....maybe with technology.
Uncle “Bob” (Robert Martin) even states in his Agile
Software Development – Refactoring and Pair
Programming book: “Refactoring, which when
done as part of Test-Driven Development (TDD)
is my personal favorite way to spend my
development time”
Joel on Software says rewriting it is the one thing
you should never do? Yet, we say we should do
it…sometimes.
Big Balls of Mud in Agile Development – Can we Avoid Them -- 48

49. Reconstruction
Big Balls of Mud in Agile Development – Can we Avoid Them -- 49

50. Can tools Help?
What is the role of tools in draining these
swamps?
What kinds of tools and practices might
forestall software entropy; is mud
preventable?
Refactoring Tools, Testing Tools, XUnit, Lint
Tools, Code Critics, …
Tools can help, but too often too much is put
on tools as the solution (silver bullet).
Big Balls of Mud in Agile Development – Can we Avoid Them -- 50

51. Testing
Big Balls of Mud in Agile Development – Can we Avoid Them -- 51

52. Draining the Swamp
You can escape from the
“Spaghetti Code Jungle”
Indeed you can transform the landscape
The key is not some magic bullet, but a
long-term commitment to architecture,
and to cultivating and refining “quality”
artifacts for your domain (Refactoring)!
Patterns of the best practices can help!!!
Big Balls of Mud in Agile Development – Can we Avoid Them -- 52

53. Silver Buckshot
There are no silver bullets
…Fred Brooks
But maybe some silver buckshot
…promising attacks
Good Design
Frameworks
Patterns
Architecture
Process/Organization
Tools
Good People ***
Big Balls of Mud in Agile Development – Can we Avoid Them -- 53

54. So Maybe Agile Can Help!!!
Scrum, TDD, Refactoring, Regular
Feedback, Testing, More Eyes, …
Good People!!!
Continuous attention to technical excellence!
Retrospectives!
Face-To-Face conversation.
Motivated individuals with the environment
and support they need.
But, Maybe Mud is why we have Agile….
Big Balls of Mud in Agile Development – Can we Avoid Them -- 54

55. It Takes a Village
Big Balls of Mud in Agile Development – Can we Avoid Them -- 55

56. That‟s All
Big Balls of Mud in Agile Development – Can we Avoid Them -- 56