Continuing on with my ramblings from last time: refactoring is a powerful tool that can help you transition your application (solution) from the complex end of the spectrum towards the simpler end.

[more]

Let’s consider our simple problem again: “Given an integer X, find the next integer larger than X.”   And our overly-complex solution: f(x) = (x^2/x) + 1.  Thanks to a little thing called “math,” we can reduce this solution back to its simplest form, our so-called perfect solution, f(x) = x + 1. 

I believe this same process holds true in software.  We can simplify a complex solution we’ve created to arrive at a simpler, more-maintainable one.  One of the best tools we have for making this transition is refactoring. 

As we refactor code, we’d like to move up this triangle.  If refactoring doesn’t move us in that direction, then we should consider whether the refactoring is actually beneficial.

One thing to keep in mind is that there isn’t a way to simplify every solution.  Sometimes there is no path leading further up the triangle from where you’re at.  If that’s true, it can mean only one of two things: either you have actually arrived at the perfect solution, or you are in a local minima: a point in the solution space that seems like it is simpler than all the alternatives, but actually isn’t.  Again, the gross-oversimplification in my head looks something like this:

To see if you are in a local minima, it may be worth backing up and starting fresh.  I’ve found that, in most cases throughout my career, the second attempt at solving a problem from scratch yields significantly better results than what I achieved the first time, even after multiple iterations on the initial attempt. 

And remember, the perfect solution to a problem may still be complex, but it will be less complex than the alternatives in the solution space.