Manage Big Ball of Mud.
Everyone wants to develop a project from scratch no one wants to manage the big ball of mud. This article is for those people who wanted to
” Leave campground cleaner than you found it”.
What is Big Ball of mud? Ref- Wikipedia.
A big ball of mud is a software system that lacks a perceivable architecture.A BIG BALL OF MUD is haphazardly structured, sprawling, sloppy, duct-tape and bailing wire, spaghetti code jungle.
Let us observe the picture to understand the difference between to manage the big ball & manage the block. Carrying the big ball is tedious instead of the blocks. When a ball is small we can easily carry and maintain. When its size increases it’s very difficult to manage. As we generally try to arrange the big balls to make some structure it is quite difficult? While If we try to arrange the blocks and structure them it is quite easy and maintainable.
How these forms?
Big ball of mud is an architectural disaster. This kind of systems has usually been developed over a long period of time, with different individuals are working on various pieces. The people who develop this kind of architecture with no formal training of what is software architecture or programming design pattern training.
There are many reasons
- No formal training of software architecture.
- No formal knowledge of design pattern.
- Financial or Time pressure.
- Throwaway code.
- Inherent Complexity.
- Change of requirements.
- Change of developers.
- Piecemeal Growth.
How to manage BBOM?
Sometimes the best solution is simply to rewrite the application catering to new requirements. But this is the worst case scenario.
The clumsy solution is that stop the new development and refactor whole system step by step. To do this
- Write down the test cases.
- Refactor code.
- Redesign & Re-architect the whole system.
To overcome this BBOM anti-pattern. You must have to follow below steps
- Code Review
- Code refactoring overtime period.
- Fallow best practices.
- Use design Pattern & architectural pattern.
- If you have time constraint while developing at least design code in a modular way (Single responsibility principle), so you can easily rearrange later.
- Use TDD(Test Driven Development).
Big ball of mud isn’t just absence of architecture rather its own architectural pattern, that has merits and trade-offs.
I am not saying here that this case is never gone happen, This happens many times with many peoples including me as well.
This article will give you a brief idea, How to manage & overcome this issue?
There is a will there is a way.
I have followed this path, love to hear from you folks.
How you are gone managing this big ball of mud?