We've all been there before, waiting at a T-cross curiously bopping our head to the right, and then the left, trying to decide which is the correct route to go. Except this time, it's not between the highway and the back-road, it's between implementing the correct solution for the problem you're facing, or doing a quick fix that you know will amass technical debt that you'll have to pay off down the road.
I recently was facing this same situation at my work. The business is pushing for a 'fix now', no matter the costs down the road. While the developers are in agreement of a sturdier, cleaner solution that will take slightly longer to implement.
It eventually falls on us developers to cash in on the technical debt, so it should be on us developers to push back and make sure the proper route is taken when confronting a Technical Debt Crossroads.
Telltale Signs You're at a Technical Debt Crossroads
- Business Pushing Timelines
When the business stresses timelines, your ears should be perking. Hearing things like "it's just a quick fix", "we need to get this out the door", or words like "band aid", be cautious. The business is trying to take a dev shortcut that will come back and haunt you in the long run.
- Not Adapting the Data Model/Masking the Real Problem
When a fix is implemented, it is often best to look at the big picture and fix it in the entire vertical stack. Adding some tricky logic to decipher the data in a way that wasn't originally intended is a sure-fire way to ensure that you'll be revisiting this code again, and not in a fun way.
- The Developer's Sixth Sense
With time and experience comes a developer's instinctual and gut feeling of 'I don't think this is right...'. It's important to come at issues with an open mind, but quite often, especially if you've been around long enough to have some battle scars, it's important to listen to your gut.
Crossing the Technical Debt Crossroads Safely
The goal for crossing such Technical Debt Crossroads in a successful manner should be to minimize technical debt in the long run, while also giving the business what they need in the short term. The main (only?) way to achieve this is with an open conversation between you, the developers, and the business or your Product Owner.
Be sure to come to this conversation prepared. You want to have a good idea of the current architecture, where the issue is, and how to go about resolving the issue at hand. A diagram or graph breaking everything down is immensely helpful, as sometimes the business just doesn't have a clear view of the whole picture. Also helpful to drive the point home would be to illustrate what the 'band aid' fix would be and why that won't solve the core of the issue.
Good luck to all the fellow developers trekking through the dangerous Technical Debt Crossroads! Be sure to look both ways and push for taking the correct path.
Photo by Lachlan Donald on Unsplash