Legacy Code is Cancer

It’s far too often that I see people shying away from newest technologies in the spirit of backwards compatibility. “We can’t move the minimum PHP requirement to 5.5 because we have 50% of our users on 5.4 still!”, they say. “There’s no way for us to move to Guzzle 4+, our back end is built on version 3 and it would take too much time and money”. I like the common argument from WordPress the best: “We can’t go full OOP and logic/presentation decoupling, because most of our users are running shared hosts with PHP 5.1 or don’t know OOP and/or MVC”.

Nonsense.

Legacy Code - a big NO

This might come out controversial, but I firmly believe there is no room for legacy code in modern systems. Allow me to elaborate before you sharpen your pitchfork and light your torch. What I mean by that is: there should be absolutely zero reason to keep implementing the functions you’re adding to the new version retroactively into the old version, just because some people are still using it, even if the people using it are a vast majority.

To clarify: bugfixing legacy versions until their long term support contract runs out or you feel like it if you’re in charge, yes. Adding new features you think up for version X into version X-1 in order not to make the X-1 users mad, absolutely and 100% not. Likewise, adding X-1 code into version X just because it can “serve the purpose” should be illegal. If you’re still charging people for X-1 and basing your upgrades on that, your business plan is bad and you should feel bad.

Who am I to spout such nonsense, though, right? I’ve never had to maintain a large project with stakeholders and boards to please, a project that moves super slow and makes everyone happy as long as it works, no matter the fact that it could, potentially, work 100 times safer and 1000 times faster, right? Not exactly. My biggest baby was a big publisher site with a complex back end, built on ZF1. If you’ve ever done anything in ZF1, you know what a vortex of painful antipatterns it is. When the application started showing signs of deterioration due to increased traffic, I rebuilt the front end of the back end (the most heavily used part of the app) in its entirety on an ajax interface and API calls, lightening the load drastically and buying enough time to rebuild the entire suite of applications we had on the only thing the higher ups allowed - Zend Framework 2. If you’ve done anything on that, you know it’s a slightly less dense vortex of antipatterns, but still a vortex of antipatterns and bloat - but what I’m trying to say here is - huge upgrades and total rewrites can happen, if capable people are behind them. If all you’re doing are agile meetings and brainstorming, there’s no amount of LTS contracts that can stop you from looking stupid in five years.

Even if you’re doing free and/or open source work, you shouldn’t break your back for X-1 users, because you’re only doing them a favor by doing a major version increment, and with it, a major upgrade with a potential BC break. They should either adapt, or wither away.

So why should we exile legacy code from modern systems?

Continue reading %Legacy Code is Cancer%

more