Why legacy is cooler than you think.
I recently started working for a start-up, Techspire, and people expected me to work on “sexy” stuff, like fintech, blockchain, AI or any other buzz-word that is hip and happening. Instead I am working on legacy software. In this article I shall explain why this is more rewarding and challenging than you may think.
About legacy
There is a reason for legacy systems to be around. If it didn’t have value the system would not exist anymore! Legacy is often embedded deep in the core processes of a company and part of the way of working.
Due to being vital to the core business, companies are reluctant to touch them. The mentality often is “If it ain’t broken don’t fix it.”. Problem with this mentality is that software is like a car in the respective that it needs maintenance. And the longer software isn’t maintained, the harder it becomes to fix problems.
Why change it now?
Reasons unknown to mankind…
But usually one or a combination of the following:
• The replacement application is delayed
• The system is getting harder and harder to work with (slow, errors, etc)
• The stack is no longer supported
Common characteristic of a legacy system
Even though each system is unique, there are a number of things you encounter almost every time.
1. The original developers are long gone, taking with them the insights into choices made for the application and the architecture. In the old days code comments were the only documentation made and the designs were done on a piece of paper or white board that didn’t survive the ages.
2. Throughout the life span of the application multiple developers have worked on it, each adding their own style, insights, solutions and libraries. New developers are brought in to fix a bug or implement a new requirement. But these developers are anxious to change too much, out of fear of braking something. And when modifying code, they forget to update the documentation, making any documentation in the code unreliable.
3. Generally, there are little or no functional tests and sadly there is usually hardly any, maintained, documentation. If there are tests, this makes life a lot easier, since there is some proof that changes did not have unintended side effects. Downside is that you also have to review the tests.
4. Everything is old. Deprecated and unsupported software is running on old hardware in a datacentre, or if your unlucky on a pc that sits in a corner somewhere in the office.
5. No version control system or management, which surprises me since version control has been a best practise for as long as I can remember.
6. No logging or monitoring. Of course each application server has some logging, but often this is not or poorly implemented in the application. Lacking monitoring makes some sense since, this is something that is still lacking in some of the modern environments I have worked in.
7. And besides the technological challenges you sometimes face organisational and interpersonal challenges. Let’s be honest most people get defensive, when they are confronted with the fact that the way they have been doing things is suboptimal and things need and are going to change. Also, the current maintainers may feel that you are stepping on their turf and feel they should have gotten the assignment, since it is “their” application.
8. Another major problem with the legacy systems I encounter is that they are badly documented and maintained.
Legacy software becoming a business risk is usually due to poor maintenance. Sometimes out of fear of breaking the system. And sadly, sometimes due to the lack of willingness to invest in the product by management. Penny wise pound foolish.
Why I love working on legacy systems
If you have read all of the common problems and issues, you may think it is a big headache, so why do I like doing these sorts of projects?
I feel legacy is not a bad thing, to me it means that an application was developed which really provides value to a business.
But to make it worse each project has its own uncommon problems, unique to the organisation and system you are helping with.
It’s not you, it’s me
A large part of why I like this kind of work is of course personal. There are a couple of traits I have that probably make me enjoy this sort of work.
In the beginning of my working life it was normal for a developer to do everything, basically from front-end to network, from database to mail server and customer support. Everything was handled by your team. Later in my career my manager told me that I had to become a specialist, focus on one specific technology and become an expert at it. Quite quickly I found out that that was not for me and luckily a new opportunity came on my path which allowed me to do what I love; making the best possible solution for the customer.
A second trait that comes in handy is that I enjoy solving problems, and that I am pragmatic in solving them.
Also, I enjoy talking to the users. I want to understand what they do, how they use the system and of course what hinders them in their day-to-day work, generally the users can provide you with better insight into the problems of an application then the operators or developers can. While Ops or Devs have the tendency to downplay problems and issues, the users do not, they just want a working system and they are proud to show you the work arounds they created to circumvent existing issues.
Do you have legacy software?
Do you have legacy software and are not sure how to move forward?
Let me do what I love, and let me have a look at your legacy systems. I would like to examine the system and advise you how to make your systems future proof again. Maybe our legacy assessment is the starting point for you.
For more information: Techspire legacy assessment
This blog has previous been published on https://techspire.nl/blogs/
About me
My name is Michiel Blijleven, I am a software engineer and teamlead for the backend team at Techspire. I have been working in IT for about 20 years, mostly as a consultant. Not stuck to a specific language or technology, I am a jack of all trades.
