Effective handling your tech debt

A simple guide to help you effectively manage the tech debt on your project.

Maxi Rosson
Mar 12 · 6 min read

As you may know, all the projects have some kind of tech debt. It’s normal, not a signal of bad developers. It’s also important to understand that even if you don’t touch your code for a while, your tech debt can increase. This can sound strange but constantly there are:

  • new ways to do things, some of them can be official recommendations of the platforms you use
  • external libraries are deprecated or upgraded

Tech debt managment should be a top priority on any development team. If you don’t have an effective process to handle this, your tech debt is going to grow to the infinite. Even if you have such a process, that’s not a guarantee of success. You need to follow it, define goals and reach them if you want to reduce your tech debt across time.

This guide is focused mainly on Java/Kotlin projects, but most of the tips can also work on other platforms too.

Kinds of tech debt

Library migrations

There are multiple reasons to migrate. Library A could be abandoned, outdated or maybe you just found a better library.

Library upgrades

Sometimes upgrading can be as easy as incrementing the library version. But when the library breaks compatibility, the upgrade can be more difficult.

Part of this work can be automated but you always are going to need some manual work. You can read this article for more info:

Language migrations

Migrating your project from Java to Kotlin is an example of this.

External integrations migrations

Migrating from JCenter to Maven Central is an example of this.

Unused source code or resources

This is a good plugin that can help you to find unused resources in your Android project:

Refactoring

Team Agreement

This is an example of some common tech debt items you could have on a Java/Kotlin/Gradle/Android project:

  • Migrate from Groovy Gradle Scripts to Kotlin Gradle Scripts
  • Migrate from Jcenter to Maven Central
  • Migrate from Legacy Kotlin Parcelize to new Kotlin Parcelize plugin
  • Migrate from Kotlin Synthetic / Databinding to Jetpack view binding
  • Migrate from Java to Kotlin
  • Migrate to Coroutines

Document on a wiki

This wiki should be your bible regarding tech debt. For each item, you could include links to official/internal documentation, migration tips, samples, metrics, reasons, etc.

Document your source code

These are some ideas of how to do that on a Java/Kotlin project:

Deprecation

TODO / FIXME

Use Legacy prefixes

Measure your progress

For each item on your tech debt wiki, just measure the number of occurrences in your code. In most cases, you can do that by counting imports or certain words in your code.

For example, suppose you defined Migrate from Kotlin Synthetic to Jetpack view binding as a tech debt, then you could measure your progress with a bash script that counts the number of kotlinx.android.synthetic imports on your code.

#!/bin/bashusages=`grep -r . -e "import kotlinx.android.synthetic.*$" --include=\*.{java,kt} | wc -l | xargs echo`# TODO Track the usages variable to your tool of choice (Grafana, InfluxDB, Datadog, etc)

You could run that script on your continuous integration tool, every time someone pushes to the default branch.

You are going to need a tool where you can store and graph your measures. Grafana is an interesting tool you can use to graph your tech debt, it can connect to multiple data providers.

You can also use specialized tools like, for example, Sonarqube, which offers thousands of automated Static Code Analysis rules.

Assign goals

Using the previous example, if you are measuring Migrate from Kotlin Synthetic to Jetpack view binding as a tech debt, and you detected 500 imports, then you could assign a goal to fix for example at least100 imports per week.

Fix your tech debt

Once you fixed a tech debt item, you want to prevent other developers from repeating the same error, increasing your tech debt again. Try to close each tech debt item as soon as possible, avoiding tackling too much different tech debt items at the same time. So, you have more chances to prevent other devs from doing things in the wrong way. For example, if you migrated your code from library A to library B, removing library A dependency declarations will prevent any other developer from using it. If you are on an Android project, you can create your custom lint rules, and make the build fail when someone does things in the wrong way. You can also have bash scripts or Gradle tasks to validate your code, verifying that no new tech debt is introduced in the code.

Follow us for more productivity tools & ideas for Android, Kotlin & Gradle projects.

Dipien

Boost your Productivity

Maxi Rosson

Written by

Developer Productivity Engineer | Android | Productivity tools & ideas for Android, Kotlin & Gradle developers on medium.dipien.com

Dipien

Dipien

Productivity tools & ideas for Android, Kotlin & Gradle developers.

Maxi Rosson

Written by

Developer Productivity Engineer | Android | Productivity tools & ideas for Android, Kotlin & Gradle developers on medium.dipien.com

Dipien

Dipien

Productivity tools & ideas for Android, Kotlin & Gradle developers.

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

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