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

61–70 of 159 posts

Re: Three Kinds of Good Tech Debt

#61

Post by WorldMaker »

theptip wrote: post #35

I like the framing of tech debt as value-neutral; whether it's good or bad depends on how you use it (just like financial debt). Of course, all else being equal, you'd rather have zero debt. One higher level consideration that's particularly relevant for early-stage startups, is that you often simply don't have time to build the ideal "tech-debt free" solution. Focusing on 80/20 solutions almost necessarily involves…

I like to point out as well that it isn't tech "debt" if there's no "IOU". For instance, in the hard-coding example, it's conventional wisdom to avoid hard-coded magic constants for a few reasons including it sometimes is hard to figure out later why a magic constant was used, and in an if/else branch situation like that maybe tough to figure out when you can cleanly refactor those branches. If the case is well documented (it's the date of a given feature release) and the code reasonably factored already (the "off" branch isn't a ticking time bomb bug that needs to be removed after the date in question), then it may be a code smell, but it isn't necessarily an IOU to a future developer (such as yourself), so it isn't necessarily "tech debt", it was just a trade off made at the time. Of course, if a future developer adopts a hard linter rule against that sort of code smell, they may come to see it is tech debt retrospectively, but that's also where the analogy starts to get fuzzy.

(Pushing the analogy to a breaking point: Is adding a linter then, doing an audit and depreciating assets for "tech taxes"? Come to think of it "tech taxes" would be a fun alternative term to add to the "tech debt" family. "Hold on, just paying my tech taxes; npm install, npm audit, and npm run lint.")

Re: Three Kinds of Good Tech Debt

#62

Post by dredmorbius »

lazyasciiart wrote: post #20
ThePadawan wrote: post #13

Earlier quoted context omitted.

Sorry, I was mentally adding "without the consent of both parties". Because otherwise, what would stop you taking on a loan for X, then paying it off after a while by taking on the same amount from another bank?

Absolutely nothing stops you. The bank you owe money to has no rights whatsoever to control where the payoff money comes from. https://www.moneycrashers.com/responsible-use-0-balance-tran...

The bank lending the money may we'll care where it's going.

A bank's primary business is managing risk. And borrowing from Peter to pay Paul (having previously borrowed from Paul) is a significantly different risk profile than borrowing for investment or even present consumption.

Re: Three Kinds of Good Tech Debt

#63

Post by tempestn »

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.

Re: Three Kinds of Good Tech Debt

#64

Post by momokoko »

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 educated gambling. You are taking a risk that the shortcuts you are taking will not pop up and hurt your company before you fix them. You are essentially saying, "We know this is a problem, but we are estimating that it won't hurt us for the foreseeable future".

The better analogy to technical debt is investing. You are getting a certain percentage increase in productivity(a dividend or other capital gain) for the (hopefully low risk) gamble that your investment will not have a problem and wipe it out or simply cause significant losses.

Developers typically do not like this because when the inevitable few cases of these "investments" turn bad, they tend to be the ones that take on the majority of the blame.

Re: Three Kinds of Good Tech Debt

#67

Post by tempestn »

hoorayimhelping wrote: post #39
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…

> If the quick hack is well documented, written in a very encapsulated and removable way, who cares about removing it later. I do. I care very deeply about removing it later. The problem is that encapsulation is often mistaken as a strong justification for existence, and code that is written tends to justify its existence just by existing. That's to say that once code is in production, it's scary to delete. It's much…

It sounds like a lot of those problems could be solved, or at least mitigated, by better communication between these developers.

Re: Three Kinds of Good Tech Debt

#68

Post by mywittyname »

wellpast wrote: post #38
nerpderp82 wrote: post #32

If you aren't spending tech debt, you don't have a sound monetary policy. Zero tech debt is not a healthy goal.

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.

I don't like the term technical debt at all. It's really just a way of saying a feature is willfully incomplete in some respect. A feature that using pulls from git instead of having a CMS isn't debt-laden anymore than a house without a garage is.

Re: Three Kinds of Good Tech Debt

#69

Post by wool_gather »

dsjoerg wrote: post #10

Another kind of good tech debt I was hoping to see here is when something is built somewhat poorly/quickly because it will give you information that you need to have in order to know whether it's worth building it any better.

I thought that was exactly the kind mentioned first:

> We realized we could build something cheap that we didn’t mind throwing away later—scaffolding—to unblock getting user feedback sooner.

If not, can you say more about the difference? I'm interested.

Re: Three Kinds of Good Tech Debt

#70

Post by Gibbon1 »

WorldMaker wrote: post #61
theptip wrote: post #35

I like the framing of tech debt as value-neutral; whether it's good or bad depends on how you use it (just like financial debt). Of course, all else being equal, you'd rather have zero debt. One higher level consideration that's particularly relevant for early-stage startups, is that you often simply don't have time to build the ideal "tech-debt free" solution. Focusing on 80/20 solutions almost necessarily involves…

I like to point out as well that it isn't tech "debt" if there's no "IOU". For instance, in the hard-coding example, it's conventional wisdom to avoid hard-coded magic constants for a few reasons including it sometimes is hard to figure out later why a magic constant was used, and in an if/else branch situation like that maybe tough to figure out when you can cleanly refactor those branches. If the case is well docum…

I have a good example of no IOU. Friend 20 years ago worked on a content streaming platform. They needed a dispatcher and someone wrote one in TCL in a week. Just to get something working. And they never got around to replacing it because it worked 'fine'. Turned out while everything else needed to be hyper efficient and scale the dispatcher not really.
Post reply on HN