Boosting developer productivity in legacy codebases

Many public sector organisations find it difficult to update and add features to essential services because they are hamstrung by legacy codebases.

There are various ways to identify legacy codebases, including the gov.uk guidelines on legacy technology. For the purpose of this blog though, we will define a legacy codebase as one that is not supported by automated tests. This lack of automated tests generally makes a codebase both unsafe to work with and difficult for technical teams to maintain and modify on an ongoing basis.

To tackle this issue and enhance developer productivity you should consider modernising the application(s) at the heart of your service so that your technical teams can work safely and effectively on your codebases.

Modernising applications to enhance productivity

Before you begin the process of modernisation, you need to be aware that it requires investment, and that this investment will need to be justified within your organisation.

An important element of this is demonstrating how legacy code affects everyone. If your legacy code results in a slow delivery cadence, this can affect your ability to reach organisational goals, and can also turn software development into an anxiety-inducing process for your team. Most importantly, it can affect your users as they suffer from buggy software that they cannot rely on.

If you are part of a public sector organisation where it feels easier to put off modernisation, you are kicking the can down the road at just the wrong time. This is because the Government Digital Service has been mandated by the House of Commons Select Committee for Science and Technology to conduct an audit of all legacy applications across government by no later than December 2020.

Before you start a modernisation project, you need to consider the risks you may encounter. Modernisation usually requires some capital expenditure up front, which may mean that you will need to hire consultants, as well as redirect your existing technical teams away from other projects. You should also consider how you will keep teams aligned, how to generate buy-in at all levels of your organisation, and how to identify any technology blockers.

You should try to mitigate these risks as much as possible, but also make clear what the rewards are for getting modernisation right. These include reducing your long term operational expenditure by increasing your delivery cadence, and minimising the need for ongoing support. You will also be able to de-risk deployments, reduce defect levels, and increase the stability of your services over time. Finally, it’s worth highlighting how modernisation can improve both job satisfaction and self-esteem levels within your technical teams.

Iterative modernisation of legacy applications

Once you have decided that application modernisation is a worthwhile undertaking, you have three strategic options for how to accomplish it. These are: iterative modernisation, iterative replacement or a big bang transformation (all of which are examined in detail in our most recent book ‘Modernising Legacy Applications in the Public Sector’).

If your main aim is to enhance developer productivity, iterative modernisation is probably the best approach to take as it is all about reviving an existing application so it is maintainable, sustainable and able to evolve in the future. It also tends to be the quickest and most cost effective of the three strategies because it builds on the technologies your technical team already knows and allows you to progress towards technical self-sufficiency.

It should be noted that this approach is only really feasible if your application is bespoke and you have access to the source code. You should also be able to see a path for the application evolving beyond the initial modernisation stage. If all of these things are in place, there is an opportunity to enhance developer productivity by following the series of iterative modernisation steps below.

Set your goals

You need to give a lot of thought to which application you choose to modernise first. To do this, you should spend time mapping the applications in your organisation by weighing the technical effort of modernising them against the business value you would gain by doing so. The ideal application to modernise first is one that has high business value but low technical effort.

Once you have chosen the application, you should focus on stabilising it by making it both maintainable and supportable. Then, you can look to enhance the application so that modifying it is relatively easy. Finally, it’s important to get your teams onboard with the strategy and empathise with them if they identify concerns about the work involved.

Start with an audit

This step is about auditing your application in its current state to establish a technical baseline of its components. This involves accessing all of the documentation that you can, as well as interviewing as many past and present technical and operational team members as possible in order to record their knowledge and insights.

From a technical perspective, you are aiming to understand as much as possible about the architecture of the application, the code complexity, and any data dependencies or integration points. By covering all these areas you should be able to identify any large-scale technical blockers to modernisation, and to plan a path to your desired state.

Implement a test harness

In a perfect world, the application you have chosen to modernise would have been built using test-driven development. If it has been, the tests in place should describe the behaviour of the application and alert you to any modifications that change this behaviour. Sadly, this is rarely the case, and so we can focus on using a test harness to get the application to this stage.

The test harness consists of a baseline testing framework along with a set of automated tests that set expectations for the existing application behaviour. This test harness creates a safety net that provides you with confidence that you aren’t breaking existing behaviour when you make changes to your application. It also provides the additional benefit of code-level documentation for developers that may work on the project in the future.

Replatform the application

This is actually an optional step which you may skip over if you only wish to modernise your codebase. If, however, you do want to migrate your application to the cloud, you should consider it as a step within your application modernisation. If executed properly, this step can provide large, ongoing cost-saving benefits, and reduce infrastructure maintenance workloads by outsourcing work to an established cloud provider.

If you do replatform the application, focus on automated deployment and automated monitoring in order to enhance developer productivity. Automated deployment involves simplifying the complexity and cadence of releases by doing a lot of work upfront, while monitoring helps technical teams to detect and resolve issues as early as possible.

Refactor the application

The Agile Alliance describes refactoring as “improving the internal structure of an existing programme’s source code while preserving its external behaviour”. This step allows developers to enhance the structure of an application so that its codebase supports (rather than blocks) future development efforts.

Having protected the application with a test harness, your team can start to disentangle any spaghetti code and upgrade old dependencies with confidence. When refactoring, the best approach is to focus on small, ongoing changes rather than on big bang transformations. And always remember, you should keep adding automated tests as you refactor!

Add new value

At this stage, your technical team will feel empowered to add new value to your applications. They will have a structured codebase to work with and a test harness to rely on, which will allow them to add new features, introduce enhancements, and fix bugs with confidence.

It is extremely important that your teams continue using the new tools and processes learnt on this journey. Your developers should keep adding automated tests where necessary to ensure the codebase remains robust, ideally using a test-driven development approach. They can then keep refactoring the codebase with confidence on an ongoing basis.

Enhancing developer productivity in your organisation

Iterative modernisation is a great way to enhance developer productivity in legacy codebases, and hopefully this article has given you a good idea of the structured approach you should take if you choose to do so. If this approach does appeal, you can find out more about code-level techniques in the following three books: