Forest header image

Symfony Finland
Random things on PHP, Symfony and web development

Leave a good legacy

The word legacy in the IT word almost exclusively negative connotations. Out of that context it is used more diversely. Consider the legacy left by individuals and organisations such Wolfgang Amadeus Mozart, Michael Jackson and the Greek and Roman Empires. The forementioned empires shed a lot of blood and caused misery, but they continue to live in our everyday lives after thousands of years. That is the power of legacy.

You can have good and bad legacy in IT as well. You could say that Windows ME was built on bad legacy where as Mac OS X was started on good legacy. But all of these have history behind them, just as the code you write today will have in the future. Most of your code is likely disposable, but it's still worth considering the legacy you leave.

First of all, please don't just curse legacy, as without it we would get nowhere. Most new inventions in the world nowadays seem to be created by refining or combining existing inventions - breakthroughs are very rare. This almost always the case in Web Development; If something is not applying good concepts from before, they are avoiding bad patterns from the past. The past may not teach you what to do, but what not to do.

The average web developer likely curses legacy a minimum of a hundred times a day. It may be Internet Explorer or old jQuery code written in 2010. Just remember if we had no IE6 we would have no AJAX. If we had no jQuery we would not have millions of developers writing front end application logic. While jQuery itself has partly been rendered useless, the API remains very common and powerful. Without IE6 & jQuery we'd have something different, maybe even something better.

Your code will be legacy

The bleeding edge application you just started writing last week is likely horrid legacy in the future. Say, you used the latest and greatest frameworks, concepts like reactive programming and LESS for the front end. There is no guarantee that JavaScript framework has staying power or LESS build tools will be available in five years.

Having no guarantee does not mean that you shouldn't move forward and avoid change. Move forward and take risks, but not stupid risks. JavaScript transpilers are pretty awesome way of writing futureproof JavaScript, as a practical example.

As is gradually rewriting running legacy applications in PHP. It is perfectly feasible and quite a rewarding task in itself. It's practical for businesses, gives you possible to maintain stability and allows improving the developer experience as you go.

PHP and JavaScript have both been reinvigorated in the last years and now, at twenty, are at the prime:

Of this pair (IMO) JavaScript is way harder to learn and master, because it can be used for so many different things in so many different ways. On the server side JavaScript may be performant and sexy, but few people know JavaScript (I don't) and it lacks legacy required by CMSes, for example. Content management is a complex problem domain that needs to be built on years and years of constantly changing requirements and real world experience.

Building a new CMS in Go is a super cool and and a great way to learn, but why not think of a completely new idea and write it in PHP? Many of the basics that you need to solve have been solved with PHP. I think having a unique idea is infinitely harder than the mechanical execution of an existing invention using an alternative tool.

Also it's common to curse the developers of the old systems' developers as flat foreheaded idiots. I would like to believe nobody on purpose writes code that is bad. Limited experience, varying tastes and circumstances do lead to horrible systems - but I can't imagine any motivation to deliberately write horrible code for the sake of it. Most old code is just that: old.

Create a virtuous circle: Build on good legacy, leave good legacy.

Written by Jani Tarvainen on Sunday September 6, 2015
Permalink - Tags: php, javascript, symfony, legacy

« Learning by doing in workshops, discussions and online interaction - Dogfooding your REST APIs »