Strategies for Dealing with a Big Ball of Mud Application
There has been a lot of discussion around programs that appear to be just a big ball of mud, i.e. very messy code patched together, with functional, architectural and other design and maintenance issues throughout. I haven’t read much on ways to deal with this other than refactoring, which is a good idea but is a very general solution to a series of specific problems. In the Strategies for Dealing with a BBM (Big Ball of Mud) application, I will discuss various ways to systematically correct the BBM issues while trying to reduce the overhead associated with a total rewrite or end-to-end brute force refactorization of the code.
The most important thing to do first when confronted with a BBM app or system is to not panic. Just like in Hitch Hiker’s Guide to the Galaxy, “Don’t Panic” is a mantra for making sure that your state of mind doesn’t lead you to rash conclusions with BBM systems. No matter how frustrating they may be, things are generally not as bad as they look at first.
Make a list of all the things that look wrong in your BBM system. Be very specific and enumerate the list just as things appear “off”, whether they are big or small. You don’t need a complete list at first, but get the major or obvious problems down. Once you have the list, go back over it and evaluate which of these are issues that just “look bad”, and which actually cause technical problems with the code.
Technical problems with code can be categorized in general as follows:
1. orphaned code problems, meaning code that will never be reached to run.
2. broken code, or code that compiles but doesn’t do what it’s supposed to do, producing a serious problem every single time this particular code is run in the system.
3. invalid temporary state code, code that works until certain state conditions are reached, at which time it temporarily becomes broken code.
4. ugly code, or any code that works “fine”, but is ugly, slow, bulky, etc.
Solving code category #1 is the easiest, because that code can simply be removed. Code category #2 is also easy to solve, because there is a clear business case for removing or repairing code that simply never works correctly. Thus, I believe that the vast majority of BBM code issues will fall into categories 3 or 4. These are issues which are either cost inefficient to repair, or issues that are difficult to diagnose, and both of these reasons are why there are so many of these issues built up over time. Since they generally aren’t repaired as they are introduced, these errors accumulate over time, causing more and more headache for developers and managers alike. The managers can’t get the budget to fix the errors, and the programmers struggle with inaccurate specifications from clients, which result in these code issues being knowingly introduced.
So how do you minimize the introduction of category 3 and 4 issues? How do you remove or repair them at minimal cost? Find out in part 2.