Big ball of mud

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