big ball of mud
DESCRIPTION
A presentation on the "big ball of mud" based on the paper by Brian Foote and Joseph Yoder. A pattern which explores the forces behind sloppy, unstructured "code jungle" software systems.TRANSCRIPT
1
BIG BALL OF MUD
ARAVINDH MANICKAVASAGAMHARIRAM SHANKAR
PRIYA DODWAD
2
What is a
BIG BALL OF MUD?
3
A BIG BALL OF MUD is haphazardly structured, sprawling, sloppy, duct-tape and bailing wire, spaghetti code jungle
They show signs of unregulated growth, and repeated, expedient repair
Information is shared promiscuously among distant elements of the system
No well defined overall structure
4
So why is this a pattern?
5
Where does mud come from?
6
The Messy Kitchen Analogy
7
“Oh that! Well Ray and Emil (they're no longer with the company) wrote that routine back when Jim (who left last month) was trying a workaround for Irene's input processing code (she's in another department now, too). I don't think it's used anywhere now, but I'm not really sure. Irene didn't really document it very clearly, so we figured we'd just leave well enough alone for now. After all, the bloomin' thing works, doesn't it?!”
8
Throwaway code Cut and Paste Code Slash and Burn Tactics Merciless Deadlines Sheer Neglect
Where does mud come from cont..
9
Time Cost Experience Skill Visibility Complexity Change Scale
Forces
10
Shantytowns
Shantytowns emerge where there is a need for housing, a surplus of unskilled labor, and a dearth of capital investment
11
Poor Investment in tools and Infrastructure
Individual portions of the system grow unchecked
Lack of infrastructure and architecture allows problems in one part of the system to erode and pollute adjacent portions
In Comparison to Software Systems
12
You need to deliver quality software on time, and under budget.
Factors: Cost, Skill, Organization
Scenario
13
Therefore, focus first on features and functionality, then focus on architecture and performance
Solution
14
Rigid, fragile system Reduced productivity over time Unmanageable code Morale Inability or cost burden of new feature
requests Code reuse is Unrealistic
Symptoms and Effects
15
Alternate periods of EXPANSION with periods of CONSOLIDATION (refactoring and repair)
Pair programming Reconstruction
Possible Solutions
16
THROWAWAY CODE
17
Prototyping Immediate fix due to Lack of Time Alternative to reusing someone else’s
complex code Time never found for follow up work
Code not usable
Reasons for Throwaway Code
18
Rewrite the code Write simple, disposable code to addresses
problem at hand Bring to attention of everyone Put comments on how it could be done
SOLUTION
19
Expect things to never break Mission Critical Operations Relationship between Businesses and
Software Two things it depends on: Workmanship Dependability
KEEP IT WORKING
20
Live System Daily / Weekly build Rigorous testing Refactoring
HOW TO ACHIEVE THIS ?
21
Process of building something a step at a time
Evaluating the current system, deciding what should be done next
Sign of not planning ahead
PIECEMEAL GROWTH
22
Before waterfall development simple code-and-fix approach
No planning or organized approach
Suitable for small jobs , does not scale well
Reasons for Piecemeal Growth
23
Do not just plan, plan to be able to adapt
Refactoring
SOLUTION
24
Do we modify the code after we delivering the application?
Shearing layer concept in architecture…
SHEARING LAYERS
25
Different artifacts change at different rates. Adaptability - The ability to change (or
be changed) to fit changed circumstances Stability - the state or quality of being
stable. - Bettering competition along one or more dimensions such as cost, quality, features, and performance. Adaptability or stability, which one to opt
for? Factor the system so that artifacts
that change at similar rates are together
SHEARING LAYERS
26
Most interactions in a system tend to be within layers, or between adjacent layers.
Individual layers tend to be about things that change at similar rates.
Things that change at different rates diverge.
Architecture example…. Separate that which changes from
that which doesn'tCan we find layers in software?
SHEARING LAYERS
27
Data and code. - Data contains details that change often and interact with users.
- Code changes more slowly than data and programmers, analysts and designers work on this. Abstract classes and components that form a
framework change more slowly than the applications that are built from them.
Objects help shearing layers to emerge - Provide fine-grained chunks of code and
behavior allowing them to be merged.
SHEARING LAYERS
28
Languages change more slowly than frameworks.
Slowly evolving objects maintain what has worked. They worked once, so they are kept around.
Artifacts that evolve quickly provide a system with dynamism and flexibility.
Resistance to change brought by of wide acceptance of components
SHEARING LAYERS
29
Hide the mess.Overgrown, tangled, haphazard spaghetti code is hard to comprehend, repair, or extend, and tends to grow even worse if it is not somehow brought under control. Comprehensibility MoraleIf one cannot easily make a mess go away, at least cordon it off.
SWEEPING IT UNDER THE RUG
30
Architectural rehabilitation Putting a fresh interface around a run
down region of the system .Re-establishing the system’s conceptual integrity Find sections that seem less tightly
coupled, and start to draw architectural boundaries.
SWEEPING IT UNDER THE RUG
31
Use of façade to put a pretty face - Expose required entities using
intention revealing selectors This can be the first step on the road to
consolidation by restricting unregulated growth during prototyping or expansion.
SWEEPING IT UNDER THE RUG
32
The code has declined to the point where it is beyond repair, or even comprehension.
Obsolescence - Technically or economically obsolete Change
- Accommodating new demands becomes next to impossible.Factors: Cost
- Software is often treated as an asset by accountants. - Rewriting a system does not discard its conceptual design, or its staff’s experience. Organization
- Rebuilding a system from scratch will demand considerable time and resources and require support from high level management.
RECONSTRUCTION
33
Throw it away and start over Previous system was written by people who
are long gone. - Re- establish contact between the architecture and the implementation - Doing a fresh draft would overcome neglect - A fresh draft adds vigor One has the experience required to do the job
properly - Participated at some level in the unsuccessful development of a previous version of the system
RECONSTRUCTION
34
When a system becomes big ball of mud…
CONCLUSION
35
http://www.ecs.syr.edu/faculty/fawcett/handouts/CSE776/PatternPDFs/Mud.pdf
http://www.laputan.org/mud/mud.html#BigBallOfMud
https://docs.google.com/present/view?id=dfdm3ghw_196tsdrvcfz
References