Ask HN: What is tech debt to you?

Tech is debt. It is best to have none, but often taking some on leaves you better off.

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.

I don't know why some devs think rewriting everything will make everything better, the resultant lost business knowledge be damned. From what I've seen the ones who advocate that usually just don't know what they're doing in general.

For what it’s worth sometimes it’s worth abandoning old legacy context in a rewrite if the new solution drastically reduces operational complexity. For example, it’s cheaper/better to retrain everyone on the new solution than it is to continue to onboard new folks to the legacy one. This is not always the case, but sometime it is as the parent comment mentions.

Can you point to an example of a software project that was re-written without the rewrite causing more problems than it solved? Joel Spolsky of Stack Overflow wrote an article on this very topic, titled "Things you should never do - part 1“

It'll definitely differ depending on who you ask in the tech industry.

'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.

> What is tech debt, really?

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.

Sometimes code is written in younger languages that are still maturing. Javascript, React, PHP, the Android SDK, CSS, etc. are very different today than 10 years ago.

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.

In my view there is no such thing as “tech debt”.

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.

You're definitely on to something here.

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 to me is something that will cause additional work in the long term compared to if it had been done in a 'better' way. However, it might still be worth accruing to gain new features or to have temporary bug fixes sooner in the short term.

Tech debt isn't always bad, but you need to be mindful of what the costs are up front and keep track of it.

Tech debt either makes changes more expensive to implement, or adds operational work to your development team. The rest is bugs, features, and stuff you want to change. Addressing technical debt should result in the ability to make changes faster or make mores changes.

Tech debt are those shortcuts now that save a unit of time now but waste 5x units of time later on.

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.

This seems to be a consequence of a contradiction at the heart of calling what we do “Software Engineering”.

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?

I see no obvious reason why software cannot be both reliable and changeable.

Whether software that is reliable but not changeable (or software that is not reliable but changeable) is good software will depend on what the requirements are for that software. Does it need to be reliable, or does it need to be changeable?

Can you see that there is effort which must be paid for it to be both?

> What is tech debt, really?

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.

The phrase “release early, release often” has nothing to do with shipping or production. The phrase comes from open source projects making their code available quickly and iteratively, often before reaching even an MVP, as part of the normal development process.

That said, your points about rushing out incomplete and buggy software do seem to reflect the status quo. Every project I have worked on in the past 10 years had technical debt that often interfered with my engineering efforts, because almost no one bothers to clean up their work after they get their branch working.

> 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".

I've been doing this for 22 years and it's always been this way :/

Tech debt should be concious Engineering trade offs made for some business benefit.

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.

> Tech debt should be concious Engineering trade offs made for some business benefit. Tech mess is on the other hand just messy code.

> Tech mess is on the other hand just messy code.

Not having coding standards, code reviews, and time allocated to refactoring for code health built in are all choices, made based on management business priorities. They may be poorly informed choices, but that’s true of the choices that result in traditional financial debt, too.

Distinguishing between well-considered tech debt and poorly-considered tech debt is certainly meaningful when you are discussing the management processes involved, but narrowing “tech debt” to the well-considered is unjustified, and blurs the fact that the impact once it exists is the same no matter whether the trade-off was worthwhile or even thought through that resulted in it.

Code that doesn’t meet the mine or the company’s “standards” for production, yet have made it into production nonetheless due to external pressures.

Seeing the same thing here.

"Let's bring it into kubernetes!"