Someone Wrote that Code on Purpose
04 Oct 2015
One of the great misconceptions of software engineering is the belief that “any code written in the past is probably wrong”. For some reason, an accepted mindset (usually among junior developers) is that older code was written with haste or by someone who did not fully understand the problem at hand, invalidating its existence.
A multitude of rationalizations may arise when the thought of refactoring software from the ground up is an option. After all, the person who wrote that code may not even be around anymore. They could have just been learning the language, surely that is a valid enough reason to completely decimate their work. What possible justification could there be for the opposite? The code just feels wrong, and I, the new domain expert, will rectify this situation!
The Devilish Details
A person who stumbles on older code can not possibly have the same level of understanding as its original author. Do not misunderstand, it is completely possible that the original author had an insufficient amount of knowledge when writing the code; however, if details have been lost between code inception and re-discovery, removing that code could have dire consequences. How dire could they be? Well according to a recent Bloomberg article, it could be millions of dollars.
According to the article:
The Core Engineering developer did not understand that the changes he made to the code sequences would affect the directed ISOs generated by Latour’s trading algorithms.
The key words to take away here is that the developer literally did not understand the code. The developer that made this mistake needed to simply understand the code that he or she was editing. However, due to time constraints, inexperience, or just plain arrogance, that crucial understanding was never reached. The small yet significant details of how the code worked within itself and with external services were never discovered, leading to a catastrophe.
Assume Smart People Wrote It
A simple rule that may help avoid multi-million dollar code rewrites is to make the assumption that the person who wrote that older piece of software is smart. With some exception, software currently running a business or application was written with care and planning. Time may have passed and the form or shape of the code might not be modern, but in those misplaced curves and edges might lurk the solution to some rarely seen and deadly problems.
In very lucky situations, the older software might be written by a current employee. This makes that person the obvious best candidate to ask about why the code might “look weird” or “does this obviously wonky thing”. Asking this person about the code or tagging them in the inevitable pull request might just save a few production meltdowns.
Take a Break and Re-visit
If no resources are present and a full code obliteration seems like the right approach, it would be wise to walk away and think for a short amount of time. Thinking about a rewrite in a relaxed environment could help make sure no bit is left unturned. Remember, the code in question was most likely reviewed, iterated on, and deliberately turned into its current state.
If solo breaks do not help get the cognitive juices flowing, try explaining the software design and purpose to an ever attentive Rubber Duck. Quackers might not offer the best repartee, but speaking about the code aloud might shine some light onto the darker bytes.
Learn and Burn
Finally, if the code has been understood and its existence is not longer required, feel free to unleash napalm and build elegant skyscrapers on top of the ruins. Because sometimes, and hopefully only sometimes, that old software hiding under a mountain of neglect really is in need of a phoenix-style rebirth. It is possible that it was written by that intern who only got the job because they were the son or daughter of the CEO’s neighbor. Maybe it was code written by an independent contractor who thought it would be funny to name their variables after famous superheros. Whatever the case may be, stopping to make very deliberate changes will pay dividends.
Taking time to understand old or opaque code can mean the difference between a healthy face lift to an application and accidentally removing its liver. How are you supposed to have a celebratory drink after a grand refactoring without a liver?