Last week I was corresponding with a former colleague who was telling me about his new job: “I really like the company, but their codebase was written by crazy people! I definitely want to rewrite it all.” I imagine this is a sentiment shared by most developers when faced with a project planned, architected and written before they came on board.
The thing that many non-developers don’t understand is that coding is equal parts science – and art. Coding is somewhat like painting: we might be working with the same “colors” – the syntax and functions available in our chosen coding language – but have quite a bit of freedom in how those colors are applied. So, like artists of other types, developers tend to have their own unique styles – evident in the way code files are organized, variables are named, or how comments and sub-functions are used.
As developers we need to keep this in mind when looking at someone else’s code. After all – Van Gogh’s Irises don’t much resemble Matisse’s – but they were both great artists.
Another part of the aversion is because experienced developers have, over time, evolved their own unique methodologies and “best practices” related to the types of projects they work on the most. I know I have! When I am used to my own “groove”, it’s jarring to be presented with something which looks so foreign to the way I would organize and implement a project – regardless of the actual code quality and functionality.
This evolution through practice is so fierce that, if presented with our own code from a few years prior, we as developers shudder with embarrassment and itch to either re-do the entire thing, or throw it away, never to been seen again. However, for live, functioning code, this is usually not an option – whether that code is our own earlier efforts, or those of another developer.
I wish I had a universal, brilliant suggestion for how to handle being faced with “legacy” code (since, let’s face it – if we didn’t just write it, it’s “legacy” to us!), but alas, I don’t. As with most things, there isn’t a clear black or white solution. In some cases, undertaking a full rewrite IS the best solution (yes, I hear you cheering, my opinionated developer friends), but in other cases a full, from-scratch rewrite is just not in the project owner’s best interest - it’s just vanity and our desire to be comfortable which pushes us toward that option.
A few things to consider, if you are in a position to make a recommendation about a codebase you have inherited:
- How old is the code?
Not everything that is old is bad (most major banking systems are still running COBOL or FORTRAN on mainframe computers, after all), but there is something to be said for evolution. Languages and frameworks tend to improve as time goes on – becoming more efficient and rich with new features. A risk with older codebases is that since some languages are supplanted with others, due to “better” (or perhaps just “more fashionable”) alternatives arising, it can become increasingly difficult to find developers who are willing and able to maintain that code in its original language. - How much has the code changed over time?
The plasticity of computer code and systems are a wonderful thing. Changes can be made constantly, based on updates to business goals or functionality requirements, but something which started out to do “A” and which now does “Z” has likely become a bit of a “Frankenstein’s monster”, with new bits stuffed in here and there, the original holistic vision lost 45 iterations ago. Especially as developers join and leave a project, more and more cruft builds up. Later developers are reluctant to completely delete old functions – just in case something, somewhere is calling them. The result is often a meandering codebase with nearly-duplicated functionality, work-arounds and abandoned areas. - How difficult (time-consuming, expensive) would a clean rewrite be?
Sometimes it’s simple economics which determines what happens to a codebase. We as developers need to be realistic about that, of course. If your honest analysis of items 1 & 2, above, points firmly towards a rewrite, you will need to sell it to the stakeholders – look for ways that a rewrite will provide extra functionality or value, reduce costs, improve performance, etc. And even if you get the go-ahead, be prepared to do it as a “side” project – while maintaining the current live system as well.
I’d like to close with some non-technical advice – have some compassion and understanding. If you are a developer picking up some else’s code – keep in mind that they likely did their best with what they had to work with, and they might be just as turned off if they inherited one of your code projects. If you are a project owner dealing with grumbling developers, know that it is often frustrating to have to maintain something they had no part in creating; and struggling to understand someone else’s code, and figure out how to do something new in a way that doesn’t damage the system can sometimes take more time that you might imagine.
