What is Legacy Software?

When people discuss legacy software, it's important to understand that everyone has a different idea of what that is.

To some people, it will be an old PC in the corner of their office that's been working for years but no one wants to switch it off, just in case their payroll doesn't work.

To others, it's a product within an organisation that has been stuck in limbo for a long time because no one can find a developer with the skills to use the language it's written in anymore.

Michael Feathers discusses this in the Preface to his excellent book Working Effectively With Legacy Code and his definition is that it is:

simply code without tests

I'd say that's a good starting point - but it also means that we're not just talking about code that was written a long time ago. In fact it means that the code you're writing today might be regarded as legacy code.

Business Accepts Legacy Software

In reality, many businesses aren't really bothered that software doesn't have tests - they want software to be making them money, and not costing them more than it costs to maintain it.

There's a point however, over the lifetime of any application where that maintenance cost will rapidly increase and will start to lose the business money. If you don't see this coming, and act on it, your costs can spiral very quickly.

How Bad Can It Get?

As an example - a payroll system has been working successfully for 18 months since the last developer that worked on it left. There's been a change in the Government regulations that means a minor change to a tax rate and the addition of a new one, and it comes into force on 1st April. Here's how this pans out:

• 1st March - 'We need someone to sort this for next month don't we?'
• 3rd March - 'Throw Junior Developer 1 at this, should only take a few days'
• 15th March - 'Has Junior Developer 1 finished that yet?'
• 16th March - 'Junior Developer 1: Kind of....turns out adding a new tax rate breaks the high percentage one, because they are in an ordered array and everything gets mixed up'
• 17th March - 'Right, we'd better get a Senior Developer on this - and bear in mind we've got less than 2 weeks to get this right.'
• 22nd March - 'Are we good Senior Developer?'
• 24th March - 'Senior Developer: Sorry, I was off for a couple of days, but it was working with all the different tax rates I could see, I'll have the change deployed tomorrow'
• 25th March - Change deployed to production, pressure off, we're all good, phew!
• 1st April - Payroll runs and the directors don't get paid.
• 2nd April - Junior Developer gets called in: 'How did you end up breaking this?'

Junior Developer: 🤦‍♀️

This shouldn't be a fairly widespread example, but I hear stories like this all the time.

There's some subtle points here:

1. It's still not fixed
2. It's cost a month of Junior Developer time, and nearly 2 weeks of Senior Developer time

If there had been a decent set of tests, then there's an element of safety, and it would have immediately de-risked that drama.

Safety

The above example is the kind of trigger that generally gets our phone ringing. The biggest problem faced by the business is that they want to add new features right now, but there's a fine balance between doing that and investing in the platform long-term.

That's a conversation that we need to have with the client, to consider priorities, and define what our approach will be.

Ideally, before any change is made, we need some kind of safety net - that is generally in the form of tests. These can take many forms, from unit tests to integration tests, but if the client can provide someone that knows the application, we can get them to write a suite of manual tests initially.

In the next Blog Post , I'll explore what these tests are and how they will help us manage change within the system.