4 ways to reduce technical debt during front-end dev

Basically, technical debt is all the development work that needs to be done to rectify any corner cutting that was done to keep the project moving forwards.

If a project deadline is far into the future, there’s no reason not to keep with the best practices. By this, I mean neat and tidy code, everything just looking nice, and working perfectly. Sections of code can be built upon, comments in code to document various workings are self-explanatory. It’s what every project should be. The dream!

But, if that deadline is brought forward, suddenly more complex sections might become a bit rougher round the edges and will take a future developer more time to maintain, fix bugs or build upon.

Shifting team members, or onboarding new ones, can occasionally rack up debt, too. If a developer comes onto the project that hasn’t had a reasonable amount of knowledge sharing, or doesn’t have the technical abilities to work on the project efficiently, they might cut corners to get things done.

For example, they might find an area in the project that looks or functions something like the end result and mould it to fit what is needed – without cleaning up any unnecessary parts of the code. What you’re left with is something that works, but is a bit of a Frankenstein’s monster.

There are a few other reasons that can come into play – some are deliberate, others not so much.

A deliberate decision could be pushing forward with development while skipping over the design phase. Developers almost “guess for themselves” as to what the end result should look and function like. Another cause of technical debt could be pushing the project live during a stage of development and being prepared to deal with any consequences afterwards.

The not-so-deliberate reasons for debt build-up could be recklessness i.e. knowingly creating technical debt due to a lack of knowledge. Or, being unaware of the mistakes that are being made along the way.

And, finally, there’s the kind of technical debt that you’re knowingly creating, i.e. after development has taken place, you become aware of a better way of doing things.

Still with me? Great. Now let’s talk about what we can do to reduce that debt.

Once technical debt is identified, it’s better to get a plan in place to clean things up as early as possible. This prevents the debt from increasing, because the more development work is factored into those areas, the harder it will be to clean up later on.

There’s been times when in order to get the project to meet the required design, front-end developers have used unsupported features in CSS files. While these use specific browser prefixes and will eventually be supported across all browsers, using these prefixes also creates a technical debt that can be dealt with later on. A good example of this would be the appearance property that currently needs prefixing with -moz-appearance and -webkit-appearance

Eventually, these prefixes won’t be needed, and can be removed to make the class more efficient and cleaner.

While we’re on the topic of stylesheets, Harry Roberts wrote about a stylesheet that exists purely to keep any known trade-offs in, so that it can be easily identified as something to work with later when reducing the debt. Keeping this separated means that when a solution has been worked out to make it more efficient to the known system, it can be removed from this file and placed in an appropriate section of the stylesheet structure. On top of this, it also allows you to do a git blame to find out when, and by who, the debt was introduced.

Debt can be minimised by providing thorough documentation at the end of the design process. This can then be built upon with new components and processes as further development work. It also means new developers can use it as a guide to pick up the project.

Interactive libraries such as Storybook – a Javascript library that allows for components to be built, documentation and tested – are also extremely beneficial when it comes to reducing technical debt.

User feedback and reviews can help identify and reduce technical debt, too. A user could already have knowledge of how the project should look/interact or be completely unfamiliar with it. All feedback is valuable!

So, to sum up – technical debt happens. In some cases it’s avoidable, in others – inevitable. But, being mindful of how best to reduce it (as a team) can help limit those future headaches and promote better ways of working. Win-win right?