This post is about technical debt, and removing some of it using Papercut, a Java library I wrote to bring attention to the problems.
Technical debt is a problem facing many developers, especially those who work on large, old projects, but it can easily start right at the beginning of your project.
The definition isn’t completely straightforward because there are many different types of technical debt. It can range from changing the visibility of a method to a fundamental issue with the design of your application. If you add technical debt then you have to pay a price later on in your project’s life. That may mean stopping feature work to refactor a class, package, or an entire library.
There are hundreds of thousands of examples on Github, of comments like the below:
//TODO remove this class
Does that look familiar to you? That is technical debt. For some reason you are maintaining, testing, and even shipping code that probably shouldn’t be there.
It’s easy to fall into the trap of adding code like this to your project, and it’s even easier to leave it there once it’s done. As developers we are frequently forced to take shortcuts in order to meet deadlines, or workaround a bug to avoid refactoring a whole class. Sadly, we will almost never be less busy, and will likely not go back to this forgotten part of the codebase to tidy it up.
While most IDEs contain a way to see FIXMEs and TODOs, they don’t force you to really consider them. Further, the existing build tools for bringing such comments to your attention treats them all the same way. You can’t pick whether a FIXME should break your build or log a warning on a case by case basis. You can’t set a priority on your TODOs without going through them manually every single time.
Papercut provides a couple of compile-time annotations that give you fine-grained management of your tech debt.