Hacker News Reader

Comment by shaan7 | Hacker News Reader

> Any piece of code that is not your own and that your app depends on adds to the technical debt of your app.

I find this ^ strange. There is a difference between using a library and technical debt. We use libraries so that we do not have to solve a problem that someone already has. Tech debt is a "shortcut" that you took when implementing a system because $deadlines/$budget/etc. An example might be calling a binary to do something for a PoC because interacting with a library will be more effort.

Using libraries is a good thing, it would be sad* if all of us keep solving the same problems over and over again. Tech debt, on the other hand, is debt, something you want to avoid as much as you can.

* personally I find having to re-solve solved problems one of the most frustrating things when programming, it takes away all the joy

View on HN

I agree and I would not call all dependencies a form of tech debt. They become debt only when you need to replace the dependency to do what you want to do. At that point the work to fix a bug or add a feature will fall to you, and it will become a debt. However to preemptively call all libraries technical debt rubs me the wrong way, combined with the author saying debt is always a bad thing. I always see debt in that context as “work that was put off”.

On the other hand, if you don’t use libraries you’ll end up with an enormous pile of technical work to do, likely outside your core-knowledge, just to get your project off the ground. Nobody can afford that, and you need to borrow from existing libraries to get your app off the ground. In that way it could be analogous to debt, but in the way that debt can be good.

I also don’t see dependencies as technical debt. In many cases they are the best implementation of a thing for that Language/Framework. Take react-navigation which is the de facto navigation library for React Native. You could argue that it should just be a part of RN but can you really make the argument that reimplementing navigation is going to give you less tech debt than pulling in this lib.

> They become debt only when you need to replace the dependency to do what you want to do.

No. It's still a liability, even if the "payments" haven't come due.

Characterising all "debt" as negative is rather strange, I will agree.

The article expands upon this point in great detail. To wit:

> Flutter's HttpServer that crashed on iOS if the user briefly switched to another app and then back to mine.

The author is seemingly capable of writing a solution to the concrete problem, and even debugging and fixing issues in simple libraries, but fixing this issue in Flutter itself (which is much more complex than a concrete solution) is too complicated, leaving him at the mercy of the Flutter maintainers.

He may be saved from solving an old problem again, but it seems that he now has a new, much harder problem to solve. In this context, I think it makes sense to describe using the Flutter library as a technial debt in your definition above.

You say that libraries are a Good Thing (tm), but how would you handle such an issue?

I think your definition of tech debt is too narrow. As with "real" debt, it can be accrued strategically (like, say, a mortgage), but you will still have to pay interest on it (in this case, by struggling to debug/fix the code). As with a mortgage, you may decide this is worth it. Or, in the case of a shortcut, you may decide it needs to be fixed ASAP, because the ongoing cost is too high.

Reply on news.ycombinator.com