Recently, we watched the excellent lunch and learn video from Hashrocket, where Sandi Metz talks about test design. While the whole video is worth watching, one thing that stood out to me was her term "Omega Mess".
Sometimes, there is something that you do based on experience, but it isn't formulated as a conscious thought. While very valuable, these understandings can become much more valuable when you are forced to explain them to someone else, because it stops being instinctual and becomes conscious.
The first time I heard someone refer to this concept was pairing with Victor Savkin, where he referred to parts of the code as his "Dirty little secrets". While this is still my favourite name for the concept, I think Sandi's name of Omega Mess, meaning a mess that is at the end of everything, is far more apt, so I have used it ever since.
Uncle Bob tells us that as professional software developers, we need to practice the Boyscout Rule, meaning always leave things in a cleaner state then when you arrive.
Imagine you are a developer, and you pick up a support task to fix a corner case bug in some crazy calculation. Now, this calculation is in a part of the application which is the stuff of legend on your team. It consists of a few thousand lines of code spread across a dozen different files with methods that have cyclomatic complexity reaching the levels of the national debt. You make a cup of coffee, put on some high energy music, and dig in.
Several hours later, you are pretty sure you understand the problem, and the interactions in code around that problem. You write a unit test to expose the issue, and go about fixing it. All you really need to do is add another if (in code already indented twelve levels deep), so you do it, the tests go green, and you breath a sigh of relief.
It is at this point the boyscout rule comes into play. You have a choice; close the task, go to a bar, and drink until you no longer remember the pain of the day, OR using the understanding you have gained over your long day of work, try do something that will make this horror slightly less horrific.
The programmer (or workplace) that believes the first is the better option is putting his short term pain ahead of the long term maintainability of the application. They will say "I already wasted a whole day on this BS, time to move on to something new so that I can be productive!".
The wise programmer (or workplace) knows that typing keys is not the only measure of productivity, and by not utilizing the knowledge gained to chip away at the vital task of improving the maintainability of this core part of the application, they are basically wasting a hard days worth of work, AND not moving forward on a task which could one day become so important that the business dies because of it.
That cautionary tale may seem like I am overly stating the importance of constant refactoring, but software shops fail all the time because they don't do it.
But sometimes, the costs don't work out. Sometimes, it isn't worth putting in the time to clean things up. Those cases are when you are faced with code which a) basically works, and b) has a very low probability of change. Code that fits this profile is always at the end of a chain of method calls which is why "Omega Mess" is such a great name; it is a mess at the end of all the things.
One day you probably want to clean it up when you have the free time, but there is also a pretty good chance that the only reason this code will ever have to change is basically if it has to be re-written. If you are working on a large enough app, this is actually a relatively common occurrence. And being a good boyscout is actually a bad thing; you are wasting your companies time for very little benefit, and you are introducing the possibility of regressions for very little reason.
This is really an experiential thing, but I would recommend asking yourself the following three questions
Is this code stable? Some code gets written once, and basically stays the same for years. Other code gets touched every few weeks or months. An omega mess is always something that doesn't change much.
Does this code touch other code? If your code is executing other code, there is now two possible reasons for this code to change. If the code it calls invokes other code, this can be an exponential thing. If code is not at the "end of the line", chances are, it is not an Omega Mess.
How many places is this code called from? An Omega Mess sits at the periphery of the system. If this code is called from 100 places in your application, it is probably fairly core, important, and needs to be fixed.