Two questions I have been asking myself recently:
- What is tech debt, really?
- Is the phrase tech debt being misappropriated to justify rewrites?
I've noticed a worrying pattern of engineers strongly rejecting the idea of maintaining inherited applications, because it's "old", "ugly", "unmaintanable". They want to rewrite, "clean", "best practices", "easier to maintain".
These are applications that work and serve millions of users a day, they are sometimes built upon unfamiliar libraries, they do things in ways you haven't seen before, but does that make them bad? Does it justify rewriting them, into your own delineation of "good code", so when you leave the next person starts the cycle again.
I've written code that is obselete within a few sprints due to the project going in a slightly different way. How is new code not subject to tech debt in the exact way older code is?
The more I see this behaviour, the less I want any part of rewrites. I am more than happy to be the person to iteratively improve on an existing, working system.
Maybe this has just become a rant, but I am curious of other's experience.
What is of concern, generally speaking, is your debt service ratio. The costs to maintain the tech relative to the benefit it brings.
If you derive significantly more benefit than the maintenance cost then your tech debt is healthy. As costs start to approach the benefit, or worse exceed it, then you have a problem. Either you need to settle your debts (give back the tech to the nothingness you borrowed it from), or refinance at a lower rate.
A complete rewrite repays the old debt and takes on new debt in hopes of a new lender providing a lower rate, but not only does this not eliminate debt the new lenders can be tricky and squeeze you when you’re not looking, more often than not leaving you with an even higher rate. The devil you know can certainly be beneficial.
'Legacy' code can exist, that itself isn't a problem, in a way everything is legacy. But, legacy code that hasn't been maintained/updated regularly, is tech debt. By updates I'd say, framework updates, fixing inefficiencies, necessary refactors, NFRs. The crud that accumulates over time to accommodate new features, which sit and languish in Jira tickets for years.
At some point it becomes more and more difficult to add features or fix bugs, and you eventually reach a tipping point where it becomes really obvious that the codebase is no longer sustainable for the future.
So there's tech debt of all kinds, part of your remit is distinguishing the true 'millstone around the neck' tech debt versus developers with 'shiny object syndrome'. As developers we don't do a great job understanding the difference.
It's gotta meet two criteria for me: 1) code that's unusually hard to maintain or extend that 2) could've been designed much better initially. So "uses a weird library" wouldn't necessarily qualify unless it's very cumbersome. "Uses a weird language" qualifies if there aren't many employees that know the language. If it's a situation in which the code could be better, but the current needs of the code were not knowable at the time of authoring, I wouldn't call that tech debt.
I don't like to talk about "good code" or "bad code". It's rarely grounded in evidence, and more often a sneaky way to say "it makes sense to me personally". Maintenance cost isn't easy to quantify but it's a step in the right direction.
> Is the phrase tech debt being misappropriated to justify rewrites?
This seems to focus on the terminology aspect more than the underlying problem -- many engineers are just more enthusiastic about new code, and some will make up whatever argument they need to spend their time on new code rather than old. So if it weren't a misuse of terminology, it'd be a misuse of something else.
I'd suggest asking people to quantify it at least a little -- could someone estimate project completion with/without a refactor to get a general sense? When I've asked my people to do that it helps us talk about whether it's worth X months to save Y% * Z features.
A codebase from that era will be harder to maintain, and get worse over time, because they use language features that have either fallen out of favor or sometimes been outright deprecated. It's legacy code that has a finite lifespan, and usually the longer you wait the harder it will be to eventually upgrade.
You don't have to be bleeding edge all the time, but sometimes it really is quicker, safer, cheaper, better just to rewrite from scratch using modern practices. Especially if the old code was poorly documented and or tested or relied on idiosyncratic nonstandard code that kept trying to reinvent the wheel.
It's tech debt when there is some identifiable reason to upgrade it or rewrite it, but that work for whatever reason was postponed and deprioritized. When enough of that builds up, the foundation of your codebase is weak and new features and bandaids begin to add more debt than they fix, if only because they perpetuate existing problems and scale them up across the codebase.
The way I look at it, there will always be a delta between the code you have and the business features you want/need. Independently of whether the code was written 30 years ago or yesterday.
So the only question worth asking IMHO is how best to reduce the delta while maximising the business value/cost ratio.
If you talk about “tech debt” without talking business value/cost then you are indulging in “what would be fun to do” and not “what is the best next step for the business”.
The biggest lie by the way is “it will improve maintenance!”. Maybe for you (because you spent years rewriting it and know it inside out) but not for the unlucky next person who has to take over your code.
Another lie is using words like “Modern!” and “Brand New!” as if it is a good thing. I want the old software that has proven itself for more than 30 years. Not the “Modern! New! Shiny!” crap that has been implemented by bright eyed inexperienced beginners, is full of bugs, implemented using a “Modern!” framework that will stop being maintained in a year, and has 5% of the features of the “old” software.
The root of the worrying pattern is that you and your team are not aligned on what Technical Debt is. Do you have a design/code review process? Do you have a coding standard? (I think these are prerequisites to alignment)
Using the unfamiliar library example, there could be a review process that happens before the rewrite that considers at least the following:
- code life: is this throwaway code or will it be used for the foreseeable future, have good enough documentation and tests to survive team turnover?
- team knowledge: what technologies are familiar/unfamiliar? What technologies should we all be learning?
- alternatives: what existing libraries are available? How well do they meet our needs?
Cautionary Anecdote: I once joined a startup. I remember the last bulleted line in the job description was "Preferred: Knowledge of functional programming languages such as Scheme". The interview process was straight C++ and no one mentioned a word about functional programming. After a couple weeks of code sifting and it became clear that a former team lead who'd recently been let go was a hardcore Scheme guy. He built and maintained a chunk of the build infrastructure which by the time I arrived had been obsoleted by a Python tool. No one else at the company understood or wanted to learn Scheme. (Nothing against Scheme BTW). The desposed team lead failed to bring themself and their team into alignment. That they were removed rather than leaving on their own indicates that they either failed to recognize the problem in time or recognized it and chose to ignore it.
You must be clear on the existing skills of your team members and realistic about what they are capable of and can be motivated to learn.
Tech debt isn't always bad, but you need to be mindful of what the costs are up front and keep track of it.
For example, not handling some edge case that rarely shows up, but when it does it causes a bunch of issues that didn't need to happen if it was made properly in the first place.
A bridge which stands up for centuries without significant change is a good bridge. This is widely agreed. Nobody expects that a bridge will change much over time. A hydroelectric dam which needs constant maintainence to avoid the killing a million Iraqis is a bad dam. This is also pretty widely agreed.
Is software which cannot be easily changed but just does the same thing for years…
A. good software because it is reliable.
B. bad software because it is not changeable.
?
Is Django good software?
Is Unix good software?
Is our field mature enough to have a clear idea of what good software is?
It's rushing things out the door without due diligence. Software these days is shipped at breakneck speed because of market competition, i.e you're not a proper shop if you don't 'release early, release often'.
This is why software should be more craftmanship rather than a frantic race, and done with love and care. It absolutely should not be rushed out the door.
I've been doing this for 22 years and it's always been this way :/
Tech mess is on the other hand just messy code.
Rewrites are rarely the best solution for either. Especially for a product that pretty much works and has paying users.
"Let's bring it into kubernetes!"