4 Ways to Make Tech Debt Great Again
4 Ways to Make Tech Debt Great Again
Technical debt can be trouble if it isn't properly managed. Find out how to manage your project's tech debt, keep it under control, and help make tech debt great again.
Join the DZone community and get the full member experience.Join For Free
You've been hearing a lot about agile software development, get started with the eBook: Agile Product Development from 321 Gang.
The cursor blinks steadily as you stare at a line of code that seemingly serves no purpose. You’re trying to fix a bug that is clearly manifested in this code, but you’ve been down this road before. Deleting it seems innocuous, but what if this is the block that sends your Jenga tower of a program crashing down? Your frustration rises as you recall the number of times you’ve asked for time to refactor and improve this project, and now you’re caught between a rock and hard place. As the table you were working at flips over in your episodic rage, you contemplate your next job and what you’ll do differently.
While this scenario is probably a bit over the top (if it’s not, you have my condolences), many development teams find themselves in the position of having to update a horribly outdated project or struggling to keep applications up to date and clean. In my last blog, I discussed ways to prevent your projects from running away in size and becoming monoliths as well as some things you can do to identify when that is happening. However, the problem many of us face is how to get the time to work on these issues. Often engineering finds itself at odds with business stakeholders or trying to squeeze major refactors into feature development.
1. Explain the Value
When we decide there’s technical debt in a project, we have a tendency, as engineers, to put it at the top of our to-do lists. We see the risk of not tackling this early on as well as the potential risk to scalability and performance.
From the business product owner’s perspective, however, this translates to lost time, with no tangible results. Most of the time, this attitude comes from a lack of understanding, especially when the product owner doesn’t have a strong technical background.
To combat this, you can do the following.
Keep Your Tech Debt Documented
Aside from keeping these things from getting lost in the ether, documenting them also lets you introduce tangible quantities of defined work that you can bring into your team’s backlogs and prioritize with the product issues.
Explain the Benefits
In these tickets, you should include a section that explains what the benefit is. Be sure to focus on the benefits in terms that the business reader will understand. Saying that you wrote some crappy code is not as effective as saying that you’ll make it easier for future developers to work on or that you’ll be able to save money by reducing the number of instances you need to run this product.
This also leads us to my next point.
2. Avoid Balloon Payments
If you are constantly rewriting a service every six months, you are going to have a hard time producing a quality product, and you’re going to have a very unpredictable amount of work. Large refactors and total system overhauls are unpredictable by nature and will have people questioning your decision making if you are constantly rewriting everything you did.
Instead, you should try to do the following.
Keep the Quantity of Work Small
Stay vigilant about identifying and scheduling your cleanup and enhancement work.
Avoid “Change the World” Commitments
Rather than having one large story that addresses a very large issue, try to divide that story into steps. Smaller steps are easier to explain and they’re easier to manage.
Stay on Top of Your Scale Limitations
If you see that your service is going to run out of runway in a month instead of a day, you’ll be able to take a much more level-headed approach.
3. Keep Services Simple
At Threat Stack engineering, we have a saying: “Complex doesn’t scale.” The more an application is responsible for, the more complex and therefore more difficult it is to update and keep performant. If your application is doing too much, refactoring requires more coordination, and there are far more risks and unknowns. If you’re proposing major changes to these services, you’ll likely affect more than your own output and risk breaking things you weren’t focusing on. In addition, the effort it takes to get buy-in to invest in your tech debt story is going to be much harder and the project is less likely to succeed.
4. Have a Technical Advocate
At previous companies, I’ve seen platform enhancement work get steamrolled by product and sales teams simply because there was no engineering voice in the meetings. Having someone who can speak up and advocate in the more senior-level conversations helps to provide a clear context as to why the project is important. Whether it’s the technical leads or the SVP or CTO, make sure you are advocating the importance of your tech debt at all levels — especially where project approvals are being made!
Ultimately, staying on top of what your tech debt is and keeping your architecture simple are the best ways to work it into your prioritization queue. Being transparent about your concerns and helping the product owners understand why the work you’re trying to do is important and what the larger effect is will help them feel more comfortable prioritizing your stories.
If you treat your tech debt like the rest of the business treats features, you can make sure it’s viewed as a first-class citizen.
Published at DZone with permission of Lucas DuBois , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.