Every development organization has tech debt. Modern development projects have gotten so large and complex that there are now dozens of libraries, frameworks, and services implemented in a modern solution. Additionally, there are always new techniques, new modules, new frameworks, new skills, and new perspectives. Applications are now ecosystems, constantly evolving, and our perspectives about them must evolve as well.
Yes, a burn down chart looks better when you pay down the debt. Yes, security flaws can force you to pay down technical debt. Yes, most developers always want to fix all the things, including impending dead technology. Modern solutions have many stakeholders. The modern roadmap has to include benefits for existing customers, senior management, the people you send into the field, and net-new customers, coming in based on new features that need to get implemented.
You can’t implement new features that help to retain customers and acquire new customers if you are always paying down technical debt. Here are 10 good ways to tell if you need to re-evaluate plans to pay down some technical debt:
- There’s a new version coming out. Let’s face it, there’s always a new version just around the corner. But a release can be imminent. Take into account the timeline of a new release and choose where to spend your precious development capital, being careful of frameworks, libraries, and services that have a new version about to come out.
- A version is too new. A cooling off period is necessary with any new technology. Otherwise, you’re learning about all the bugs and limitations of a new solution in real-time. The larger a development organization, the longer it takes to develop the institutional assets required to perform a large-scale effort to implement new technology. And the greater the risk if you go the wrong direction. For example, if you are already updating production applications to Angular 2, are you sure that’s a good idea?
- You have to retrain an entire team. Retooling an entire scrum team, or larger efforts require you to rethink how you approach various problems, and can require hundreds of hours of training for engineers. When you are looking at larger projects, consider how much time the new tools will save versus the cost to bring in experts to train your staff, as well as the hours required to actually do the work.
- You can’t hire talent that know the new technology. This is a huge red flag. Maybe you can’t hire someone to help you out because the supply is tapped, maybe you’re trying to implement a framework that’s too new, maybe the library is too old, or maybe it just plain sucks. Either way, if you can’t find engineers willing or able to implement, rethink the whole situation.
- The cost of doing the project is greater than the cost of other efforts if you do not do the project. Not paying down technical debt accrues interest. That interest can build up over time. But what if it doesn’t? What if the new project makes others more complicated, or doesn’t simplify others? Consider the impact to other initiatives, both positively and negatively when prioritizing your technical debt; especially smaller projects.
- You have to replace other parts of the solution to make the new parts work. We’ve all been there. You have 4 libraries that don’t work with the new framework. If you start the implementation of new technology, you’ll want to check on each interconnected framework and library prior to beginning to do so, if only so you can properly estimate the time required.
- Solutions come with new licensing requirements. As noted, most modern projects are ecosystems of dozens of open and closed source libraries (if not more). Many teams now keep a document, or entire database, of the types of licensing used for each of the building blocks that make up the stack of a given application. Each time you update to a new version, you’ll want to first validate that you aren’t entering into an entirely new set of licensing terms.
- Initial tests go poorly. OK, so you don’t need to scrap a project just because projects where you attempt to scratch the surface go poorly. I like to start with some small wins, stick my toes in the water, and then re-evaluate timelines based on how the initial tests go. You want to get some nice momentum on the burn down chart before you head into deeper waters when doing larger development projects.
- You can’t compartmentalize the new technology. Let’s say you’re implementing React Native into an application. You already have a user interface that users have been using for, in some cases, several years. Can you implement React on a screen-by-screen basis, or given the architecture of your existing app, will you have to do the whole thing at once? If you can’t compartmentalize the new technology, is it really right for you?
- You are spending more to pay down technical debt than on new features. Mature products often get you into a place where you’re spending more to keep up with your existing code base than you spend to implement new features in your tools. When you get into this kind of scenario, you definitely need to stop accruing technical debt; however, you should re-evaluate whether a much larger rewrite would be more appropriate than fixing little things here and there.
- Your goal can be accomplished in another way. Let’s say you have an API, and you never bothered to ship documentation on using the API. This is actually pretty common. There are tools like HATEOAS (https://spring.io/understanding/HATEOAS) that can allow you to basically self-document the API within the API. Is it better to do that or publish a quick PDF on using the API? Either way, you need the PDF. Most of us would, if time allowed, prefer to go the HATEOAS route; however, again, we have to be judicious with our time.
Ultimately, we all have a limited pool of resources. And as our solutions grow, the amount of effort required to update parts of the code will grow as well. A lot of these tips involve taking into account the resources required to update the building blocks of a larger application, or project or timing. There’s no doubt that the longer you incur the debt on each of your initiatives, the more interest each incurs. But sometimes, it’s important to keep a larger picture in mind.
With limited resources, there is no right answer when it comes to keeping your code modern. You don’t want to accrue too much technical debt. Otherwise code will become unwieldy and developers will run away from your organization when they realize just how much of a hurdle it will be to update your code. But you have to implement new technology in order to keep from keeping up with 30+ year old FORTRAN code in 2016. Next time product management and developers compete for prioritization, check these tips, and see if you’re going down the FORTRAN route, or keeping too modern; hopefully it’s somewhere in the middle.