whateverthing.com

☰

You've probably heard people talk about "legacy code". They're usually referring to systems that are no longer supported or updated. However, there are other types of legacy code out there. Code that was written years ago, but still runs your company's products every day. Often an unruly mess of hacks justified by shifting business requirements and the airy whims of management, it's your job to keep it maintained and working.

Since people seem to think it's easy to just go in and presto-change-o add a feature, I'd just like to point out a few things that complicate that process. These three threats conspire to make the Total Cost of Ownership of a codebase hard to predict, and they are why you should use best practices at all times to ensure that you aren't willfully strapping yourself into a straitjacket in the name of short-term savings.

Antiquated Code

Code that is tightly bound to an older methodology can be OK, but only if the original methodology is sound and well-conceived. Often, the older way of doing things stemmed from a series of hacks, with no thought given to being particularly well-designed. This comes up in all kinds of projects, but in my experience it's a far worse with PHP codebases. You'll find projects that have one "php file" for each page, projects that have several thousand lines of code in a monolithic include, or projects that have a whole bunch of classes but no actual object oriented design.

One key thing that these antiquated PHP projects suffer from is a huge amount of code duplication. That means that every time you add a feature, you have to manually analyze the entire codebase to ensure that you haven't broken an existing feature - and you often have to make the same change in dozens of places.

Additionally, some antiquated architectures (I'm looking at you, one-file-per-page) make it very difficult to implement security-related functionality or to refactor the code into a cleaner configuration.

This can require hundreds of wasted work hours to correct, and in theory it could make your system vulnerable to hackers - I know from experience it can certainly make system architectures fundamentally unscalable.

Antiquated code can kill your company's ability to respond to success-driven security and scaling issues.

Dead Code

Imagine this scenario: you're troubleshooting a load issue on a server. You find a script that runs every hour, and spikes your CPU load to 100%. You analyze the code, you find that it's a series of highly inefficient database reporting queries, so you spend a few hours trying to optimize them ...

... then you find out where the results are used: NOWHERE. That's right - thousands of hours of CPU time, hundreds of gigabytes of generated data, and it is NEVER used.

Before you begin writing your submission to The Daily WTF, make sure to disable the cronjob and mourn the thousands of dollars flushed down the toilet over the past X years the project has been live.

When dealing with legacy code, always make sure you know both the cause of the issue and the affected portions of the codebase. You may regret going down the rabbit hole, but sometimes there's a payoff.

Dead code can cost your company money if you let it linger.

In-House Code

A lot of companies choose to internalize their projects and do everything themselves. From writing their own frameworks to writing entire toolchains internally, these companies have to tread carefully to avoid wasting time and money.

What often happens, especially with companies that started writing PHP in the 2000s, is that the entire codebase is written with custom in-house implementations of now-common framework libraries. These in-house implementations are often riddled with bugs or usability issues (and dead or antiquated code), and there is usually no spare time to clean up the codebase. This cruft holds the company back, because so much time is spent putting out fires in internal framework code that could be spent on moving the company's portfolio forward.

That's not to say that in-house code should always be avoided - it's just that external solutions need to be fully researched AND EVALUATED before making the informed choice to develop internally. Even then, I would strongly advise companies to consider open sourcing their internal alternatives. There's a good chance that if your company needs the tool/framework/library, other developers might also benefit from it. Your company could actually reap the benefit of an active open-source developer relationship - your formerly-internal project could receive contributions from the wider community, thus preventing stagnation and accelerating forward progress.

Companies like Netflix and Etsy have taken advantage of this cultural change, and it has boosted their profile quite a bit in the development community.

In-House code can hold your company back. At the worst of times, it can even cripple your ability to innovate.

The Legacy Continues

When embarking on new projects, your company should always consider the full cost of ownership for the project. The earliest architectural decisions can have grave impacts in the years to come, from scaling issues to stymied innovation.

The maintenance cycle of a project is not just some abstract concept; it is the writhing, suffocating cost of running your company.