Hacker News Reader

Comment by mjr00 | Hacker News Reader

Also 6: tech debt being another term for "code I personally do not understand," or "software written in a way different than I would write it." The article calls this out;

> Turns out some apparent tech debt was actually code that was better left untouched, had there been better documentation. We documented what we would not refactor or remove.

> Better clarity on the design and architecture of the code, enabled us to make better judgement calls when we had to cut corners due to the time constraints.

There is certainly real tech debt. But I have lost count of the number of times in my career I've heard a bright, but less experienced, developer claim that because a certain piece of code uses Formerly Popular Framework A from 7 years ago when it was written instead of Current Popular Framework B, it is unmaintainable tech debt, despite it having tests, a working CI pipeline, working monitoring, etc.

View on HN

It maybe tech debt depending on a lot of context, with old tech you get into a lot of situations like this:

https://stackoverflow.com/questions/9318895/how-to-integrate...

Sure, there is an answer to the question, it is a little messy, not too bad, do this 30 times and you have a disaster to maintain.

Formerly popular is also a red flag, over time it will get harder to hire. Resources and documentation will go black.

> It maybe tech debt depending on a lot of context, with old tech you get into a lot of situations like this:

Yeah absolutely that's a fair example of tech debt, where a tech stack is so old that it's difficult to impossible to support modern features. But "classic ASP doesn't support this modern feature requested by product" is a lot different than "I don't like working with classic ASP."

> Formerly popular is also a red flag, over time it will get harder to hire.

Really depends. Java is a great example. Very unsexy, not too many startups beginning life as a Java shop, most code is likely "legacy" by this point. But Java is so ubiquitous, if I were a Java shop I wouldn't be worried whatsoever about running out of Java expertise anytime soon. Maybe in 50 years.

On the other hand, if you were a legacy Java shop that jumped on the Scala hype train at its peak 8-10 years ago, or God forbid you built something in Haskell when it was getting touted as the next big thing, you're in a far more precarious situation. Ironically, many Java shops tried out Scala as a way to move their Java codebases forward, and now their now-legacy Scala 2.xx codebase is a way larger technical dumpster fire than their Java codebase.

> Also 6: tech debt being another term for "code I personally do not understand," or "software written in a way different than I would write it."

Sometimes it's quicker for me to implement a desired change on a code that was written long ago by someone who is no longer with us by re-writing that part of the code in the way I understand it, and then implementing the change, as opposed to trying to understand the code and implement the change in a way that aligns with it.

When Framework A is unmaintained and therefore has known, unpatched security defects then migrating away is critical tech debt that needs to be prioritized. In my org frameworks are actually our largest source of tech debt issues.

Example: Somebody years ago bet on Angular 1.x, migration to 2+ was deemed “a near-total rewrite” and postponed, so now we have to rewrite in React or whatever flavor-of-the-month. The same happens with Java, .NET, and other backend frameworks.

This is a good one. I've seen (and probably made...) some refactor PRs where someone takes an old system and breaks it up into new conceptual chunks. Code reviewer comes in and they find the new code makes even less sense than the previous code. Of course it so happens that the reviewer already knew the old code, and so it's only natural that new code is less legible to them.

There is apparently a disconnect between refactoring, rewrites and green field development and maintenance and long term support.

How often do developers who are quick to move to the next shiny thing held accountable for years after?

How often do they ask the hard and boring "What if" questions?

How much is empathy a driving factor in these decisions?

I'd argue code I don't understand is indeed tech debt. not sure what you were implying with your statement, but I sounded as if you disagree with the statement. undocumented code that no one knows is a serious tech debt issue. time should be taken to read it, understand it, and document it.

Agreed that code that nobody in the team understands is tech debt; code that only a few people in the team understand is a liability, but not directly debt. Whether you understand the code yourself shouldn't immediately cause it to be labeled as "debt", unless you're the I in team (which can easily happen for personal projects or badly-managed organizations).

Reply on news.ycombinator.com