Three Ways to Reduce Technical Debt
There are many places you can go to find out what technical debt is, or isn’t, but what can you actually do to tackle the debt once you can identify it?
“Technical debt has a direct correlation to how many expletives you yell when making any changes to an existing codebase.” — Evan Fribourg
Papercut
It just so happens that I’ve written a Java library to help you.
Below, I’ve highlighted three ways you can use it to improve your code.
Highlight It
If you know you’re adding technical debt to your codebase (it happens) then you should highlight it. If you don’t make it clear that it’s technical debt then it will disappear into the depths of your codebase, silently waiting to ruin your day in the future.
The usual way of highlighting technical debt is to add a comment. This probably looks familiar to you.
//FIXME This is a horrible mess, refactor later
private void doSoemthing() {}//TODO Delete this
private void doNothing() {}
Unfortunately, when you come across this comment in your codebase in the future you’ll probably be too busy implementing something else to context switch and refactor.
IDEs and compile-time tools like Checkstyle can help you find highlighted technical debt in your codebase. You can set Checkstyle to fail your build if it finds a TODO or FIXME comment, but this isn’t really practical for existing codebases with many such comments already in place.
Papercut provides you with a couple of annotations you can use instead of, or alongside, the comments. These annotations can be used for fine-grained control of technical debt.
In their simplest form they look just like the comments.
@Refactor("This is a horrible mess")
private void doSomething() {}@RemoveThis("This is not needed")
private void doNothing() {}
By default the @Refactor annotation will trigger a warning during your build, and the @RemoveThis annotation will trigger an error, failing your build.
Set Targets or Deadlines
If you’re already ignoring the various comments in your codebase why would you pay attention to the annotations?
The annotations can accept a variety of deadline conditions that trigger their behavior at compile time. If you have a particular date that you expect the technical debt to be removed then you can specify it in the annotation.
@RemoveThis(value = "Horrible hack", date = "2017-12-01")
public void quickAndDirty() {}If you want to remove or refactor by a certain release you can specify a version code or version name.
@Refactor(value = "Lazy implementation", versionName = "2.0.0")
public void acceptableForV1Only() {}You can also define your own milestones with the @Milestone annotation.
public class FutureMilestones {
@Milestone("LOGIN_REDESIGN")
public static final String LOGIN_REDESIGN = "LOGIN_REDESIGN";
}public class ImageFetcher {
@Refactor(
value = "Use new API",
milestone = FutureMilestones.LOGIN_REDESIGN
)
public Bitmap fetchProfilePicture() {}
}
When you have reached a milestone just delete the constant in the FutureMilestones class. Your IDE will highlight all references to the milestone.
If you extend or remove the conditions that you added then you are actively avoiding tackling your technical debt. This should raise eyebrows in a code review, or cause you to sleep a little less easily at night. Why set a deadline you can ignore?
Factor in Refactoring
Once you’ve highlighted your technical debt, and you’ve set deadlines you only need to worry about paying it down.
Most development teams I know of use some sort of agile development process. Sprints and Kanban boards both give you ways to start removing your technical debt.
In my experience the backlog is usually prioritized by the people who push to introduce technical debt to meet a deadline. If they have to prioritize removing technical debt from the last feature, into the work required for the next feature, then they should be less likely to push for repeating the mistake.
Failure to address technical debt only leads to a worse codebase, unhappy developers, and unhappy customers.
“I have yet to meet a developer who enjoys working on shit. If your company doesn’t make time for quality, good developers won’t make time for your company.” — Frank van den Brink
Try It Out
Check out Papercut on Github. I welcome your feedback, feature requests, and bug reports.
Papercut is not the only way to achieve the three points above, but for Java and Android developers I hope it makes it easier.