There has been a noticeable slowdown in the pace of new features on the departments and policy publishing platform. Not that we've been resting on our laurels, far from it. Instead we’ve taken a conscious decision to spend some time dealing with a problem that, left unchecked, can very easily cripple a software project.
The cost of rapid development
The GOV.UK Departments and policy publishing platform has been developed at breakneck-speed. In little over a year, we have:
- moved over 100 government departments and organisations to the new publishing platform
- added support for localised content in over 40 languages for our users around the world
- migrated several thousand email alerts lists, serving over a quarter of a million subscribers
It's quite an achievement, and everyone on the development team is very proud of the amount we have delivered in such a short period of time. But going so fast comes at a cost. One such cost is the trade-off between code quality and speed of delivery. The faster you go, the less time you have to write code that is easy to maintain and work with. This in turn affects your ability to deliver quickly in the future.
There is a great metaphor that helps us understand the implications of writing software quickly, and that is Technical debt. Martin Fowler describes it beautifully:
Technical Debt is a wonderful metaphor developed by Ward Cunningham to help us think about this problem. In this metaphor, doing things the quick and dirty way sets us up with a technical debt, which is similar to a financial debt. Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort that we have to do in future development because of the quick and dirty design choice. We can choose to continue paying the interest, or we can pay down the principal by refactoring the quick and dirty design into the better design. Although it costs to pay down the principal, we gain by reduced interest payments in the future.
To deliver so much in such a short period of time, we have had to take on such debt.
To be clear, technical debt is not necessarily a result of sloppy programming. Taking on technical debt in the short term is often a deliberate decision so that working software can be delivered quickly.
The metaphor also explains why it may be sensible to do the quick and dirty approach. Just as a business incurs some debt to take advantage of a market opportunity developers may incur technical debt to hit an important deadline. The all too common problem is that development organisations let their debt get out of control and spend most of their future development effort paying crippling interest payments.
Too much technical debt will seriously impact the longterm productivity of a team. As a codebase increases in complexity and the technical debt mounts, it becomes more difficult to work with. Adding new features gets harder, takes longer, and the number of bugs will generally increase.
But because of its insidious nature, the cost of technical debt is easy to underestimate and is often ignored until it's too late. It's important that the whole team, both technical and non-technical, understand the implications of technical debt and work together to keep it under control.
Declaring technical debt bankruptcy
Here on the Departments and policy publishing team, we've decided it's time to implement our own austerity plan and invest time in paying down some of our technical debt.
Firstly we’re targeting key areas of the codebase where the debt is having the most impact, specifically around edition workflow and attachments. This involves rewriting existing code to improve the overall design without directly changing the way the software behaves from the perspective of you, the user. This is often referred to as refactoring.
Secondly, we are taking extra care to minimise the amount of new debt we introduce with new features.
Finally, we are spending more time fixing the non-critical bugs that have tended to fall down our priority list. Although these bugs aren't usually showstoppers, they often highlight debt that needs dealing with. Minimising broken windows also helps to maintain overall code quality.
The impact on you, the user
The nature of this works means that we'll be delivering fewer features in the short-term. Longer term however, this important effort will help us maintain our speed in future and greatly reduce the number of bugs in the publishing platform.
Stay in touch. Sign up now for email updates from this blog.
5 other GDS blogposts we think you might find interesting
GOV.UK one year on
Choosing Go for a new project (GDS technology blog)
Building a new router for GOV.UK (GDS technology blog)
How many people are missing out on JavaScript enhancement? (GDS blog)
Do we need British Sign Language on GOV.UK? (accessibility blog)
1 comment
Comment by Graham Ashton posted on
I'm so pleased to hear this is happening; it's so important to keep on top of it. Nice work. 🙂