Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Three Kinds of Good Tech Debt

engineering.squarespace.com

Post reply on HN
Print view View original

71–80 of 159 posts

Re: Three Kinds of Good Tech Debt

#71

Post by k__ »

momokoko wrote: post #64

I've always believed that "debt" is not a great term for this. Because it does not really apply to financial debt. Financial debt is often repaid simply by bringing in more revenue because of the benefits gained from bringing on the initial debt. The only risk involved in the debt is that there will not be enough money to pay it back later. It is a very predictable and obvious issue. Technical debt is closer to educa…

To me they even sound the same after you explained them.

Not being able to pay back money sounds like the same as not being able to fix bugs.

Re: Three Kinds of Good Tech Debt

#72

Post by onemoresoop »

I'm not sure how this classifies as tech debt, but in my experience the worst type of tech debt is found in parts of a system that is relied upon and whose business logic has become unmaintainable, is too complex/poorly understood and is not possible to throw away as too many things depend on it. Also usually whose initial creator is long gone, the documentation is conflicting with the code implementation. This kind of debt causes eternal confusion and constantly lowers the productivity of the team. In cases like these, workarounds are created and more tech debt accrues on top of it that is even harder to reason about. Nobody sane can fix a mess like this and the only hope is death of the system or complete overhaul.

Re: Three Kinds of Good Tech Debt

#73

Post by munk-a »

Tech Debt is never good, but it can be acceptable in exchange for a greater gain.

So, just like this article's opening:

> Financial debt isn’t universally reviled in the same way. Your friend takes out a mortgage to buy a house and what do you say? Congratulations!

Except it is universally reviled, no one wants debt - they just accept debt in reasonable quantities as a way to efficiently get things done.

I think, in particular, the success of not-quite-agile-but-similar business practices has confirmed this, plan carefully and evaluate business needs, then get it done in a way that's fast and leaves you relatively free of debt - don't plan for everything. So don't get stuck in analysis paralysis trying to build the perfect things - and don't just code with no thought of the future... it's a difficult road to follow.

Re: Three Kinds of Good Tech Debt

#74

Post by Gibbon1 »

dspillett wrote: post #12
ThePadawan wrote: post #4

Earlier quoted context omitted.

The term "debt" is really helpful. It also explains that while you can pay off debts by taking on other debts, there is a good reason why this is illegal (if done with money) in the real world. Technical debt in your solution is fine. Running a Ponzi scheme in your solution isn't.

> there is a good reason why this is illegal (if done with money) in the real world. Erm, it very much isn't illegal. At least not in most places. Taking on fresh debt to pay off other debt is the very definition of a consolidation loan which is perfectly legal in most, possibly all, jurisdictions. There are limits of course, like not using a loan to pay the deposit on a mortgage, or simply not lending beyond defined…

In the brick and mortar world rolling debt is common.

Re: Three Kinds of Good Tech Debt

#75

Post by jamie_ca »

gmueckl wrote: post #31
julianozen wrote: post #6

Two points I really enjoyed: > Not Fixing All the Edge Cases We’ve all seen bugs that occur so rarely, and fixing requires destroying some part of the original design architecture. The ability to acknowledge these types of bugs as not worth fixing is liberating. > Err on the side of building too little because you can always build more later. Build things to be easy to throw away and replace; I find developers tend t…

Writing hacks and throw-away stopgap solutions is generally a bad idea in reality. The only time when it can actually be allowed is when it it concerns a feature that is a pure leaf in the system with nothing else built on top of it. If you violate this rule and build other features on top of shortcuts, two things will inevitably happen: you will have to replace the shortcut with a proper solution eventually (it is o…

Yes, it's more time overall, but that's not the point.

From the example in the article, if it would take them 2 months to build a robust email delivery system or 2 weeks to put a temporary hack in place, it could be worthwhile to the business to do the hack if it means they can start user-testing 6 weeks earlier.

Also, if they're still in the product-fit stage of their business development, they might find that the product isn't as useful/worthwhile as they thought, and scrap it after 2 weeks testing. This would allow 6 weeks of overall developer effort to be spent on another initiative.

Just because you know that developing throwaway code is waste, doesn't mean it's necessarily a bad business decision.

Re: Three Kinds of Good Tech Debt

#76

Post by eikenberry »

tempestn wrote: post #63
davnicwil wrote: post #59

The article links tech debt to financial debt early on, and this is exactly what the analogy is - it is best to be as literal as possible about it. What is good debt? It's taking money from someone, promising to pay them back more money in the future, and using the original money to make even more money than that , so both you and the lender profit. Good tech debt is just the same. It's taking shortcuts now to save t…

> I think mostly where it goes awry in the wild is people forgetting the paying it off part. Which also fits the financial debt analogy perfectly.

What would bankruptcy be analogous to... the business going under? Having to rewrite the application due to unmaintainable code?

Re: Three Kinds of Good Tech Debt

#77

Post by eikenberry »

tomnipotent wrote: post #44
marcosdumay wrote: post #27

Earlier quoted context omitted.

Building things to be easy to replace often does not mean quick hacks. Quick hacks are most likely hard to trow away, not easy. Building things to throw away means componentizing your code, that is extra work overall.

> Building things to throw away means componentizing your code No it doesn't. You can really tell who has and hasn't worked at a start-up by the responses to OP.

He's right that it doesn't mean quick hacks, but it doesn't really mean "componentizing" either. It means keeping it simple. Don't over-engineer it (componentize it) but don't use some ugly hack or cut-n-paste off SO either.

Re: Three Kinds of Good Tech Debt

#78

Post by wellpast »

Raidion wrote: post #41
wellpast wrote: post #38

Earlier quoted context omitted.

Unlike financial debt, which has a clear quantitative measure, Tech Debt is an incredibly fuzzy concept to the point of being useless for anything other than covering one's ass. We can do better as engineers than resting on such fuzzy thinking.

But that's the point. It is a fuzzy thing. Software is built on business priorities, not technical ones. These align a decent amount of the time. Spending the extra time and money to set up tests is very much worth it. Is it worth implementing a cache layer in a system? One on hand, you have a better system that can handle more load, on the other, you've spent time that could be spent doing something else. Your syste…

> Is it worth implementing a cache layer in a system?

This isn't a "Tech Debt" thing. This is a feature/scoping thing. Does my system need to handle 1M concurrent users? If so, support that. If not, don't support it.

But we don't need the absurd concept of "Tech Debt" for effective analysis. We can be specific. We can be clear. Does my system need to support low latency in the face of 1M concurrent users? Yes or no. Now proceed.

"Tech Debt" is such a ridiculous dodge to otherwise avoid real analysis, real work, real clarity.

Re: Three Kinds of Good Tech Debt

#79

Post by mcondit »

eikenberry wrote: post #76
tempestn wrote: post #63

Earlier quoted context omitted.

> I think mostly where it goes awry in the wild is people forgetting the paying it off part. Which also fits the financial debt analogy perfectly.

What would bankruptcy be analogous to... the business going under? Having to rewrite the application due to unmaintainable code?

oh it definitely is a rewrite

Re: Three Kinds of Good Tech Debt

#80

Post by wellpast »

davnicwil wrote: post #59

The article links tech debt to financial debt early on, and this is exactly what the analogy is - it is best to be as literal as possible about it. What is good debt? It's taking money from someone, promising to pay them back more money in the future, and using the original money to make even more money than that , so both you and the lender profit. Good tech debt is just the same. It's taking shortcuts now to save t…

> The article links tech debt to financial debt early on, and this is exactly what the analogy is - it is best to be as literal as possible about it.

Financial debt has a clear quantitative measure.

Tech Debt is an incredibly fuzzy concept, even as a qualitative measure, to the point of being useless for anything other than covering one's ass. We can do better as engineers than resting on such fuzzy thinking.

Post reply on HN