Big ball of mud


Published on

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.

Published in: Technology, Business
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • //prototyping: not concerned with how elegant or efficient the code is //finally meant to be thrown away//used to prove a conceptImmediate fix //banking application…//keep postponing the fix//
  • //publicly let everyone know it’s a workaround/ flaw in the system/ bring it to attention
  • Refactor: S/W design is not thought of, divide into classes and functions, improving the quality of the code whatever you need to considerYou need to have quality system same as the development server where in you can make checks for testing Write test cases and try and run the test cases on all the modules that are present, all test cases must pass
  • Each step consists of evaluating the current system, deciding what should be done next (what should be fixed or improved) and then adding a piece or making a change.
  • //no co –ordination between the code
  • Big ball of mud

    2. 2. What is aBIG BALL OF MUD? 2
    3. 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 3
    4. 4. So why is this a pattern? 4
    5. 5. 5
    6. 6. 6
    7. 7.  “Oh that! Well Ray and Emil (theyre no longer with the company) wrote that routine back when Jim (who left last month) was trying a workaround for Irenes input processing code (shes in another department now, too). I dont think its used anywhere now, but Im not really sure. Irene didnt really document it very clearly, so we figured wed just leave well enough alone for now. After all, the bloomin thing works, doesnt it?!” 7
    8. 8.  Throwaway code Cut and Paste Code Slash and Burn Tactics Merciless Deadlines Sheer Neglect 8
    9. 9.  Time Cost Experience Skill Visibility Complexity Change Scale 9
    10. 10. Shantytowns emerge where there is a need for housing, asurplus of unskilled labor, and a dearth of capitalinvestment 10
    11. 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 11
    12. 12.  You need to deliver quality software on time, and under budget. Factors: Cost, Skill, Organization 12
    13. 13.  Therefore, focus first on features and functionality, then focus on architecture and performance 13
    14. 14.  Rigid, fragile system Reduced productivity over time Unmanageable code Morale Inability or cost burden of new feature requests Code reuse is Unrealistic 14
    15. 15.  Alternate periods of EXPANSION with periods of CONSOLIDATION (refactoring and repair) Pair programming Reconstruction 15
    16. 16. 16
    17. 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 17
    18. 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 18
    19. 19.  Expect things to never break Mission Critical Operations Relationship between Businesses and Software Two things it depends on: Workmanship Dependability 19
    20. 20.  Live System Daily / Weekly build Rigorous testing Refactoring 20
    21. 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 21
    22. 22.  Before waterfall development simple code- and-fix approach No planning or organized approach Suitable for small jobs , does not scale well 22
    23. 23.  Do not just plan, plan to be able to adapt Refactoring 23
    24. 24.  Do we modify the code after we delivering the application? Shearing layer concept in architecture… 24
    25. 25. Different artifacts change at differentrates.  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 25
    26. 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 doesnt Can we find layers in software? 26
    27. 27.  Data and code. - Data contains details that change oftenand interact with users. - Code changes more slowly than data andprogrammers, analysts and designers work onthis.  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. 27
    28. 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 28
    29. 29. Hide the mess.Overgrown, tangled, haphazard spaghetticode is hard to comprehend, repair, orextend, and tends to grow even worse if itis not somehow brought under control. Comprehensibility MoraleIf one cannot easily make a mess go away,at least cordon it off. 29
    30. 30. Architectural rehabilitation  Putting a fresh interface around a run down region of the system .Re-establishing the system’s conceptualintegrity  Find sections that seem less tightly coupled, and start to draw architectural boundaries. 30
    31. 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. 31
    32. 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 considerabletime and resources and require support from high levelmanagement. 32
    33. 33. Throw it away and start over  Previous system was written by people who are long gone. - Re- establish contact between thearchitecture and the implementation - Doing a fresh draft would overcomeneglect - A fresh draft adds vigor  One has the experience required to do the job properly - Participated at some level in theunsuccessful development of a previousversion of the system 33
    34. 34. When a system becomes big ball of mud… 34
    35. 35.  outs/CSE776/PatternPDFs/Mud.pdf allOfMud dm3ghw_196tsdrvcfz 35