Technical Debt for Clients

In development, releasing code as a quick and easy approach is like incurring debt.
“Close-up of lines of code on a computer screen” by Ilya Pavlov on Unsplash

Many of our development projects use WordPress as the CMS. Recently, we’ve had several clients come to us wondering if it would be cheaper and faster to just buy an off-the-shelf WordPress theme and use it as the starting point for developing their website. The idea being that they would buy a $50 theme, have us install it and then code the extra functionality based on their business needs. The answer is…it depends.

We often talk about technical debt without actually realizing it. The metaphor technical debt was first used by programmer Ward Cunningham in 1992.

Technical debt is a concept in programming that reflects the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution. — Techopedia

The technical debt metaphor originates from financial debt. Just like financial loans incur interest so does design and development. The extra effort to code future enhancements depends on the quality of the underlying structure. You wouldn’t build a 3rd level on a house without a solid foundation.

In development, releasing code as a quick and easy approach is like incurring debt — it comes with the obligation of interest, which, for technical debt, comes in the form of extra work in the future. Taking the time to refactor is equivalent to paying down principal. While this takes time in the short run, it also decreases future interest payments.

Imagine two options for building a website. The first is the quick way by installing a theme, knowing that it will need future functionality. The second has a better strategy and design but will take more time to implement. Which one are you going to take? If you weren’t going to make any modifications to it, probably the first choice. But if you intend to use it as a basis for development then choose the second.

Two reasons:

  1. You won’t need to learn and get into the mind of another theme programmers code.
  2. You won’t inherit the technical debt that comes with that theme.

And before you think it, yes, all systems have technical debt. If you’re using WordPress, you are inheriting WordPress technical debt. Same goes for plugins. This is the reason we rely little on plugins. The majority of functionality we custom code based on the client requirements.

One aspect of technical debt is that it’s usually unintentionally hidden from a project timeline or deliverables. It’s impossible to measure. The interest payments hurt a team’s productivity, we can’t see the true effect until we miss a deadline or something takes longer than it should.

There are cases where technical debt takes a back seat. For example, testing a concept, or getting a solution or website out faster to market. You don’t want to carry too much of a balance on your credit card. Neither do you want to use that quick solution as your main product. The debt might cripple you.

Like what you read? Give Lionel Mann a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.