I'm tackling the biggest programming task I've faced in quite some time as part of my fork of Open Eats. The code is in good working order, but it's a few years old and relies on a lot of outdated libraries, most notably, Django.
It's at this stage that I could take a few paths - I could ignore what's there and completely write my own site; I could take the requirements and just rewrite everything from scratch with those requirements; I could leave everything in place and build off of the older foundation; or I could undertake the maintenance effort to upgrade the system. I chose the last option. Though I do generally opt for fixing what's there, it's not always straightforward, and I think this article does a good job of outlining some of the reasons why.
In a professional atmosphere, one of the big questions companies need to ask themselves is - do we move forward to get the latest feature set out there and risk incurring technical debt, or do we work on technical debt and risk falling behind on the feature curve? There's no definitive answer, as it requires a balancing act. Start ups, because they only have a toe hold in an industry, usually opt for features. More established companies have the luxury of working on infrastructure projects (in fact, anyone at a start up who's advocating the use of microservices is probably an overzealous advocate of software engineering trends).
However, I feel that in both cases, small and large companies tend to do maintenance programming wrong. Even large companies attempt rewrites of portions of their code base and through their 'best' (usually read most prolific or most pedantic) programmers at the problem. This seems to be based on the human perception that if something's broken, starting anew will not only fix it, but improve it. Unfortunately, when rewriting something, people often ignore the lessons of Dr. Heidegger and continue making the same mistakes over again while contributing new bugs to the rewrite effort.
The only time I could ever advocate rewriting something from scratch is given the following conditions - (a) the requirements are well defined, meaning the problem set the software solves is relatively self-contained (b) no one at the organization either understands the project's code or has the ability to delve into it and (c) everyone realizes that the new code will miss existing features and surface new bugs.
If those conditions aren't met, it's better to maintain what's there than it is launch a new greenfield project. If you're making arguments like (a) it'll take too much time to maintain the existing project, or (b) it's too hard to rewrite because there's no safe way to rewrite the code (i.e. there's insufficient testing around the project), you're probably making the wrong argument. For (a) you're ignoring the time you'll need to learn a new technology or process, and you're certainly ignoring the time to fix the new bugs and update the features you forgot about during the initial rewrite. For (b), if you can't safely figure out what existing code can do, why do you think you can figure out something that has yet to exist?
This isn't to say that, via maintenance channels, you can't completely rewrite your entire stack. You just go about it from a renovation point of view. Don't bulldoze the house and blow up the foundation just to re-pour it. If the floors are worn (or you need an ORM to replace your aging JDBC code), sand the floors and refinish them. If the kitchen is outdated (or you need some semblance of an MVC framework to replace your hand-crafted version from 2000), install new counters and appliances. If you need a new addition to the house (or need to get off Java 1.4 and have the option to use something newer, like Go), draw up the plans and do the work to make sure it fits well with the existing frame.
Sure, maintenance programming doesn't have the starry-eyed narrative of perfectly formed code springing forth from the head of a genius architect, but the ultimate result takes no less intellectual effort and is no less rewarding in the long run.
No comments:
Post a Comment