• Save
BBOM-AgilePT-2010
Upcoming SlideShare
Loading in...5
×
 

BBOM-AgilePT-2010

on

  • 1,429 views

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 ...

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?

Statistics

Views

Total Views
1,429
Views on SlideShare
1,134
Embed Views
295

Actions

Likes
3
Downloads
0
Comments
0

2 Embeds 295

http://www.agilept.org 220
http://2010.agilept.org 75

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

BBOM-AgilePT-2010 BBOM-AgilePT-2010 Presentation Transcript

  • Big Balls of Mud in Agile Development – Can we Avoid Them? Joseph W. Yoder Copyright 2010 Joseph W. Yoder & The Refactory, Inc.
  • 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
  • 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
  • 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
  • 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
  • Big Ball of Mud Big Balls of Mud in Agile Development – Can we Avoid Them -- 6
  • 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
  • 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
  • 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
  • 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
  • Legacy == Mud? Big Balls of Mud in Agile Development – Can we Avoid Them -- 11
  • 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
  • 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
  • Question So, why DO people build Big Balls of Mud?
  • Where Mud Comes From Big Balls of Mud in Agile Development – Can we Avoid Them -- 15
  • Software Decay Big Balls of Mud in Agile Development – Can we Avoid Them -- 16
  • Robber Crops Big Balls of Mud in Agile Development – Can we Avoid Them -- 17
  • Keep it Working, Piecemeal Growth, Throwaway Code Big Balls of Mud in Agile Development – Can we Avoid Them -- 18
  • Copy „n‟ Paste Big Balls of Mud in Agile Development – Can we Avoid Them -- 19
  • The Age of Sampling Big Balls of Mud in Agile Development – Can we Avoid Them -- 20
  • Big Bucket of Glue Big Balls of Mud in Agile Development – Can we Avoid Them -- 21
  • The Mystery of Dark Matter Big Balls of Mud in Agile Development – Can we Avoid Them -- 22
  • They Have a Name Big Balls of Mud in Agile Development – Can we Avoid Them -- 23
  • 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
  • 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?
  • 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
  • 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
  • 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
  • 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?
  • Shoddy Workmanship Big Balls of Mud in Agile Development – Can we Avoid Them -- 30
  • Amish Furniture Big Balls of Mud in Agile Development – Can we Avoid Them -- 31
  • The Quality Goes In Big Balls of Mud in Agile Development – Can we Avoid Them -- 32
  • 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
  • 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
  • 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
  • “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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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?
  • Total Code Makeover Can we just Refactor out of Mud? Big Balls of Mud in Agile Development – Can we Avoid Them -- 47
  • 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
  • Reconstruction Big Balls of Mud in Agile Development – Can we Avoid Them -- 49
  • 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
  • Testing Big Balls of Mud in Agile Development – Can we Avoid Them -- 51
  • 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
  • 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
  • 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
  • It Takes a Village Big Balls of Mud in Agile Development – Can we Avoid Them -- 55
  • That‟s All Big Balls of Mud in Agile Development – Can we Avoid Them -- 56