Refactoring: Paying Off Your Technical Debts

Every software runs into technical debt sooner or later. If developers keep it under control and manage to pay it off on time, there is nothing to be afraid of. If they don’t, the situation can grow out of control making further development extremely hard or even impossible.

Today we’ll talk about one of the most popular practices for dealing with technical debt — refactoring.

Technical debt: definition

There is only one problem: This is a definition for developers. If you have never coded yourself or you don’t have really deep insight into programming, you probably didn’t understand a lot from this explanation, not to mention you probably don’t know the best practices for paying off technical debt.

So, how can we understand technical debt without referring to coding? Tech debt is better understood as a metaphor for the time and manpower that are spent on changing or maintaining a piece of software. Basically, it’s a maintenance cost for adding more features, like the ability to endure heavy loads, phone number authentication, or anything else you might want your piece of software to do. The cost is measured in time: How many days does it take to implement a feature, and how many programmers are needed to do it?

Technical debt is the main cause of an app’s bugs and instability. It looks quite like financial debt: If you continue to accumulate more and don’t repay it for a long time, more costs will appear, and it will become more difficult to get yourself out and implement changes.

Reasons for technical debt

All programmers are afraid of “spaghetti code” which no one, even the original writer, can understand. “Spaghetti code” is a slang term for unstructured and difficult-to-maintain source code. This situation can be caused by several factors, like often-changing project requirements, a lack of programming style rules, or insufficient experience.

Spaghetti code is complex, interlinked, and hard to read. It causes software systems to behave unpredictably and can significantly increase the cost of adding features or bug-fixing. You can lose weeks, months, or even years of programming time trying to deal with this mess.

Spaghetti code has more chances to occur if software grows too fast. Managers often insist on running a project cheaper, so they either hire too few developers or hire too many inexperienced ones. Regardless, the code will suffer from such an approach to programming.

Other common reasons for tech debt include:

  • Lack of technical documentation
  • Excessively interdependent server/network (when one server goes down, all the rest do the same)
  • Nonfunctional backups
  • Poor or outdated design
  • Unnecessary complexity of code

A project with huge ongoing technical debt is similar to a poorly built house: The structure as a whole may look nice, but in reality, it can fall apart at any moment just because someone pushed the wrong button.

What is refactoring?

If you don’t know much about coding, it’s good to understand refactoring as a feature that is measured in the time needed to refactor the code successfully and how many developers are needed for it.

Refactoring makes the code easier to maintain and reduces code size that, in turn, allows for the quick and predictable implementation of further changes. Moreover, new features for your software will be added faster and more smoothly.

There are many ways to refactor the code, but some typical refactoring techniques might include:

  • Reducing the use of duplicate or copy-paste code
  • Abstracting or splitting code into smaller and more understandable pieces
  • Improving code readability
  • Regular testing

This is only a small list of the best practices used for refactoring. Experienced programmers refactor all the time, and practice “clean coding” techniques that minimize tech debt.

When should you pay your technical debt?

But usually refactoring goes a bit differently. Agile companies typically clean up and organize all the code after every sprint (about every two weeks). Others might do it after the implementation of a new feature or update, but this way is less effective.

When your engineers tell you they need to refactor, it means that technical debt is becoming a large problem. You can expect development tasks to take at least three times longer, but the maximum amount of time is unlimited. Moreover, if your tech debt is truly heavy, adding new functionality to your app can become simply impossible.

You want to pay your technical debt when the cost of refactoring grows beyond the cost of making a new feature.

When can you get away with it?

In a startup or an experimental division, you can start the development with an MVP (Minimum Viable Product). Generally, an MVP is the first version of your product, consisting of just the core features. Its goal will be to sign enough paying customers to pay your programmers, and then repay all the tech debt once you have revenue coming in.

Tech debts should be paid only when the savings are tangible in the real world.


Originally published at

A team of engineers writing about web & mobile applications, here’s how we think ( and live (

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store