Sometimes through the best of intentions meeting customer expectations and getting critical functionality out the door we create a mess. So what happens if the organic growth of complexity reaches the critical point? Obviously it needs to be addressed, or this rats nest of code will seriously impact your ability to maintain the project, or worse it impacts the performance and stability of the application.

There are all kinds of rats nests that lay in wait ready to spring into your code. These range from overly complex processing to a series of database updates and reads that should be packaged up and optimized better. These complexities come from performance optimizations, or from needing to track more meta-information about your project’s data. Sometimes the complexities start out with a poor design, but most of the time it comes from a decent design that just wasn’t cleaned up.

Analyzing the Problem

The first thing to do when analyzing a rats nest is to document the before and after states. What should the data look like when we perform a certain action? Any solution that breaks this contract will cause problems in the application. Once we’ve documented what the application is doing that we don’t expect, the first thing to do is to remove those changes from the system. Since we are in the documentation and analysis stage, we just have to cross out those actions from the change package.

The next step is to figure out how to cleanly make sure that the end result is what we expect, and that there is no surprising work done. Having simple, well defined packages of change will help you get a grasp of the next steps you need to take. It can also provide its own performance improvements as the system isn’t doing unnecessary work.

The final step of analysis is to figure out how drastic the change has to be. Can you get away with a few key changes? Do you really need to rewrite whole sections of code? In essence, this is where we assess the risk of the proposed changes. Are there ways to mitigate the risks and go through with it? Can we perform the work in stages spread out over more than one release? How long is it going to be to make these changes? How long would it be to pursue an alternate solution.

Solving the Problem

There are several ways to manage the structure of your code, and one size definitely does not fit all. Something like Design Patterns by the Gang of Four (Gamma, Helm, Johnson, Vlissedes) provides several common object oriented solutions to common programming problems. Too many people have used this book as the “Holy Grail” of software development and have erected crystal cathedrals of software in homage to the GoF. It’s a tool to help you think of ways of solving a particular problem. It’s not the doctrine of all software design. Nevertheless, don’t throw the baby out with the bath water. You can use solutions listed in that book, but implement them differently than they suggest.

Perhaps the right solution would be the “command pattern” which lets you create an object that performs the logic for a change. Assuming you have a fairly low number of changes, this can be a very clever solution. However, if the number of command objects suddenly explode into a large number it can introduce its own management problems. The command pattern can be an attractive way to deal with a finite set of complicated database transactions.

Maybe you need a proper Finite State Machine (FSM) and use the “state pattern”. With each state having a well defined start and end point, you can easily test the individual states in isolation. Just don’t forget to test the whole set together.

No matter how you choose to solve the problem, you have to ensure that you have adequate testing. Make sure that the changes you need are the only things being changed. For example, nothing else should be touched with your information than what you intended to touch. Being creative, you can build a testing infrastructure that extends your unit test tool to check whether values have changed that should remain the same. In fact unit testing is even more critical with cleanup work.