How we deal with Technical Debt on BBC Bitesize

BBC Bitesize has been online since 1998. It was the BBC’s first digital-first product and has been represented on the web by many different applications over those years.

The current incarnation was launched in 2013 as the Knowledge & Learning beta.

The Knowledge & Learning Beta was one of our first projects on the BBC’s (then rather new) Forge platform. As it evolved into Bitesize, and as more and more features were added, we accumulated a lot of Technical Debt.

We found that our ability to estimate how long a piece of work would take became increasingly difficult and the number of bugs we were generating was continually increasing.

So we developed a strategy to properly deal with it.

Technical Debt? What’s that?

There’s no doubt an abundance of Technical Debt in the applications you work on. As we build new products and add features we make decisions that we know will require our future selves to do extra work and deal with the ramifications of those decisions.

There’s also numerous external factors that will introduce Technical Debt into your product without you introducing them directly.

Technical Debt has evolved to mean many things:

• Poorly written or poorly implemented code
• A lack of test coverage, or testing the wrong thing
• Code or infrastructure that doesn’t scale well
• The need to keep software or infrastructure up to date
• The desire to meet the evolution of development best practise
• Out of date design or UX patterns

The problems it causes

Technical Debt reduces the agility of a team. It restricts their ability to make the right decision and forces further short term thinking.

In many of the teams I’ve worked in Technical Debt has been a major source of angst.

The Engineers were always keen to ensure that anything we developed was implemented ‘the right way’, and that we took adequate time to refactor code that didn’t meet best practise.

Our Project Managers saw the effect Technical Debt was having on their delivery estimates and felt like Technical Debt was a massive time sink.

Product Managers were hesitant to devote time to dealing with Technical Debt, instead preferring to focus only delivering features to users.

The net effect is that everyone feels bogged down and restricted by the problems.

The benefits of Technical Debt

Too often Technical Debt is seen as a negative part of building a product — the positive effects of accruing that debt is often forgotten.

On BBC Bitesize our objective is to bring relevant learning material to our audience and prepare them for school and exams. We deliberately accrue Technical Debt to get new content or new features in front of our audience quickly.

Building a perfect system is not only time consuming it’s impossible to get it perfect first time. Not only that, the risk involved is engineering the perfect product before putting it in front of your audience is massive.

If a feature fails to hit the mark or doesn’t work well in real world testing, it’s much easier to write off a couple of weeks work than 6 months of engineering effort.

Dealing with Technical Debt

Despite the accrual of Technical Debt not always being bad, we know it can hinder future product development.

On Bitesize we use a number of techniques to try and tackle it at the right time and accumulate it in the right way.

Delivering new features

When implementing a new feature we look at the quickest way to get that feature in front of a small proportion of our audience to quickly learn how it’s used. Sometimes that means accruing debt by hard coding a datasource or implementing a mobile only UI.

Once that feature is unleashed we can look at the usage patterns and understand how the feature should evolve. Scaling these features to new sections of the audience means dealing with that accumulated Technical Debt.

We then swap out the hardcoded data for the correct service call, implementing appropriate caching behaviour to ensure that it can handle increased traffic, or add the responsive version to improve the experience on other devices.

This means that we achieve those goals of putting new features in front of our audience and deal with Technical Debt as part of the process.

Maintaining or enhancing new features

When enhancing a feature the first thing we do is assess if there is any Technical Debt in the same area that needs to be addressed.

We’ll then make sure that the refactor happens or the improvement is made before starting the new feature work. We do this before estimating how long a piece of work might take and factor it into how we work.

This allows us to focus on dealing with Technical Debt that will actually make a difference rather than refactoring areas that are working fine and not affecting our work.

Understanding when Technical Debt is unavoidable

Feature work is our bread and butter but often issues arise which aren’t necessarily caused by how we chose to implement something.

• Security patches for libraries we use often need updated
• Services we consume make changes and we need to update
• Performance degrades as content and dependencies change
• Operating systems and infrastructure need updated
• The frameworks we use need updated

In these cases we make sure to understand and communicate the effect these have on our applications. Typically we’ll add them into our backlog and address them immediately to avoid them adding up and causing huge disruption later.

Follow the Scout Rule

When working on our applications we try to follow the Scout rule. In essence it means that when we see wee problems while working on features we tidy them up there and then.

We don’t make big deal of it — it’s just seen as part and parcel of development. There’s one caveat though if there’s any risk that it might have a knock on for the application then it needs to be flagged to the rest of the team — especially our testers.

Avoiding technical debt

Often Technical Debt can be accrued not necessarily by moving too fast, but by not thinking through how something should be implemented.

Just because we want to deliver quickly doesn’t require us to write poorly thought through code. If you’re busy, keep things simple and talk to fellow engineers about the solution.

We find paired programming and peer reviewing strategy before writing any code helps enormously with this.

So what next..

Depending on your situation and workplace some of these strategies might work or you might find they just don’t apply.

On Bitesize we found the best place to start was talking through the issues as a team. We used this guided conversation question set to help us understand the issues and build a strategy that works with our applications and processes.