Big Ball of Mud: How do you avoid it ?

"A Big Ball of Mud is a haphazardly structured, sprawling, sloppy, duct-tape-and-baling-wire, spaghetti-code jungle. 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."

This quote comes from in Brian Foote and Joseph Yoder's in their paper of the same name http://www.laputan.org/mud/ 

What Techniques do you emply to avoid creating a Big Ball of Mud with your code?

Is Agile development the answer? Doing all your design up front, if so how? ... or just plain common sense?

Also why not tell us about your experiences, or hints and tips to help out if you come across one and need to fix it?

This is a common problem and everyone is going to have an opinion so why not let us know.

(Ideal thread for a first post!)

I think you can mainly avoid it by knowing what it is and why it's bad.

Actually, I'm just reading this book which deals with adding unit testing and refactoring to big balls of mud.

I'm only a couple of chapters in, and I can already recommend it to anyone who sees a gap between the theory of unit testing/refactoring and the code they deal with in real life.

Herbie

Personally for me, XP and the Agile Method works well.
However, there still needs to be a balance of doing design work up front.

You need to logically think about the design before you begin construction or (IMHO) the agile method loses some significance because you end up in a vicious cycle of re-factoring as new features or business requirements are realized.

Also, don't be an XP zealot; I have had the displeasure of being part of a team that took XP to a ridiculous level. There was a mandate that every single action needed a test case, including button clicks and other intrinsic features.

Writing 100+ lines of code to subclass a button and wireup pass-through events via custom delegates, just to make a button click testable complicates the design and implementation.

I say keep it as simple as possible, use your head and think about what you are doing and why you are doing it before beginning construction, and keep that mentality through the life-cycle of the project.

Also, I love the "Single Responsibility" model. 1 Class for every action. It makes re-factoring features so much easier.

Requirements will change, re-factoring will always be necessary, but if you have a sound foundation and have encapsulated processes, it makes life simpler.

There are those who see Agile code as "all over the place".

I don't share that opinion, and I don't get to use the methodology.

There are those who cannot value code style beyond there own, and that's a pity.

Perhaps "other people's code" is nearly always a ball of mud. At least in proportion to how much respect one holds for the authors to begin with.

Creating good standards and sticking with them should be enough.

I always choose to emulate the authors of the language; and teams like Patterns & Practices. Those are the standards I would follow, given freedom to do so.

The system I'm working on was a ball of mud. But I managed to silently replace subsystem by subsystem at a time, and one and a half years later the whole system has been straighten out.

I'll say about 80% of the system has been rewritten... (I'm contently to keep those static layout "as is") so basically noone aware of it (I'm the only one work on the code when the change is made) except maybe the fact that it doesn't fail now. (Solved a concurrency issue that otherwise would not be detectable in the ball of mud)

cheong wrote:

I managed to silently replace subsystem by subsystem at a time, and one and a half years later the whole system has been straighten out.

My experience with the Big Ball of Mud has been similar to this. Working in the Financial Services Industry, I have encountered numerous Excel / VBA Spreadsheets and  Bloomberg VBA / API code that has been put together hap hazardly by analysts and traders in an effort to achieve a near term goal.

I dealt with this by introducing small changes in small modules / classes one by one.

Here is an example.

Some of the trading analytics was in spreadsheets (.xls ) saved on network folders. These spreadsheets had hard-wired links to other .xls spreadsheets. Besides that, there was no control over the changes made to these spreadsheets.

When I had to make a few code changes to these analytics and deploy them properly,

• the first thing I did was to convert all the spreadsheets to templates (.xlt).
  
• the second thing I did was to create an add-in with menu, that would internally instantiate the templates, so that users don't have direct access to the templates and hence don't make unauthorised changes and bring the setup down.
  
• the third thing I did was to store configuration information for location of the templates in an xml file, and added functionality within the add-in to browse and set the location for this xml file. I used MSXML to parse the xml file and load it into a hash table style "Scripting.Dictionary" object in memory.
  
• finally, I wrote a .vbs script for deployment of the new analytics, which would take an environment as parameter (ex DEV or QA or PROD) and according set the xml file within the add-in before copying it over to the user's local add-ins folder.

Ofcouse, this is a very simplistic example. But I have taken this approach and used it in more complex application and have achieved similar results. Also, the move from mud to magic takes quite a bit of time and includes some resistance from some of the end users as they want their "fixes" immediately, so don't expect 'Instant Gratification' in your efforts to change this