Three Kinds of Good Tech Debt • Hacker News Board

Re: Three Kinds of Good Tech Debt

#121

Post by wellpast » Tue, Aug 13, 2019, 8:34 PM UTC

aeorgnoieang wrote: post #97

wellpast wrote: post #80

Earlier quoted context omitted.

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

I'm curious what you think is better. Any links you could share? I suspect you're wrong, or not quite right, tho. Technical debt is a great analogy and even if it's fuzzy, being able to think about the relevant tradeoffs in a familiar way is too useful to ignore. Surely there are situations in which it's only useful to cover one's ass, but often it's a great way of explicitly understanding specific tradeoffs being ma…

At any given crossroads in a business endeavor, you encounter a problem.

Now you have two choices:

1) You select and articulate your assumptions. You select and articulate your requirements. You also may try to capture and articulate your Black Swan list of unknowns and risks. The key thing is that you are clear. Clear what you know and clear about your concerns and risks. You then articulate your solution, holding it accountable to your assumptions, requirements. And then you move forward.

- or -

2) You come up with some solution sketch. You have a general vague notion that it isn't ideal. You're not sure why but it just doesn't feel right. You need a way to psychologically contend with this vagueness. So you give the vagueness a name. The first thought that comes to your head is: "Vague Notion That This Design is Not Very Good". This is not very flattering to your ego. So you think a little bit more and come up with: "Tech Debt". And you like this, because it sounds quite nice. It sounds like you're back in control, that you know what you're doing. You proceed to blame the design deficiencies over time to "Tech Debt". Everyone nods their heads.

Re: Three Kinds of Good Tech Debt

#122

Post by wellpast » Tue, Aug 13, 2019, 8:39 PM UTC

skybrian wrote: post #92

wellpast wrote: post #80

Earlier quoted context omitted.

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

Yes, it's a nebulous metaphor. Taking it too seriously is a mistake. But I'm not sure we can do much better? What would you suggest? I like the Go concept of aji [1] but that's too obscure, nobody will get it. Maybe something like "unfinished business" would work? A nebulous term for a nebulous concept. [1] https://senseis.xmp.net/?Aji

What I suggest is you try to run a project and deliberately avoid reaching for the concept of "Technical Debt".

You will find yourself squirming a little. It will be uncomfortable at first. But if you hold to your guns, you will find that you're forced to speak in much more clear terms about your process and decision-making.

And you will certainly find yourself saying humble things like "I have a sense that this isn't the best solution, but it's all I got right now."

But over time you'll find yourself improving. You'll find yourself saying "I have a sense that this isn't the best solution -- oh, you know what I just realized, this design choice is going make this other requirement over here nearly impossible to implement."

And with this kind of clarity you'll be in a much much better position to navigate the territory ahead and make clear, conscious decisions based on what you know and don't know.

"Tech Debt" is simply a way to dodge -- e.g., dodge the discomfort of not knowing stuff, of holding yourself to clear thinking, of admitting the need to improve...

Re: Three Kinds of Good Tech Debt

#123

Post by stingraycharles » Tue, Aug 13, 2019, 8:42 PM UTC

gmueckl wrote: post #91

jamie_ca wrote: post #75

Earlier quoted context omitted.

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 p…

Is it worth the while when you have to spend more than weeks to do it right later? Again, in general it is not. You are citing a very, very specific business reason as a justification. In 99% of all cases, no good business reason exists to waste more money later. Essentially, this is what you are asking. In your example, it's either 8 weeks total to do it right in the first pass or 10+x weeks total to do it right lat…

You have to look at it differently: if you hack something in two weeks, you will:

- be able to switch to other, more important tasks more quickly;

- allow the business to better discover what the actual requirements are while they have an MVP solution in place.

Resources are finite: you only have a limited number of engineers, and the business needs to be moving forward. This approach allows you to do so, while mitigating a lot of risks at the same time.

The costs are not lost: they bring back business value in terms of fast progress, and mitigates risks.

Re: Three Kinds of Good Tech Debt

#124

Post by caymanjim » Tue, Aug 13, 2019, 8:42 PM UTC

TheLastPass wrote: post #101

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…

One important difference between tech debt and financial debt, is that if the project you accrued a bunch of tech debt in gets killed for unrelated reasons before it's completed, your debt is forgiven. You never pay it off, and you never have to. When you're validating an idea, don't worry about making everything perfect. Worry about validating the idea. Once you're more confident that you're actually gonna do it lon…

> One important difference between tech debt and financial debt, is that if the project you accrued a bunch of tech debt in gets killed for unrelated reasons before it's completed, your debt is forgiven. You never pay it off, and you never have to.

This happens with financial debt as well. It's the risk that drives interest rates. Financial debt is abandoned (or restructured) when people or companies file for bankruptcy, when homes are foreclosed on, etc. Sure, it might ding your personal credit history in some cases, but financial debt is constantly abandoned at little or no cost to the borrower.

Re: Three Kinds of Good Tech Debt

#125

Post by [deleted] » Tue, Aug 13, 2019, 8:42 PM UTC

jdance wrote: post #100

I take a chance and say it right out: Fix some kind of image library functionality! As a customer who's also used Wordpress (everyone?) its just madness that I have to keep originals on disk somewhere to post it onto another page. I can hardly figure out how to download the full size original to be able to upload it again. I ask you humbly, please, you have the power to improve my life! If you want me to stay on topi…

[deleted]

Re: Three Kinds of Good Tech Debt

#126

Post by LargeWu » Tue, Aug 13, 2019, 9:03 PM UTC

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…

A good talk about the "technical debt" metaphor.

https://www.youtube.com/watch?v=XakfJ2spb3w

tl;dr: Technical debt can be categorized on 2 axes: Planned vs unplanned, and high interest vs. low interest. Interest is paid down in pain. If you are not experiencing any pain, it's not actually tech debt.

Low interest, planned tech debt (akin to a mortgage) is ok because presumably the cost of the interest is lower than the returns.

High interest, unplanned tech debt (akin to a loan shark, or pawn shop) is best to be avoided, because you're experiencing a lot of pain probably without a clear vision for paying it off. You're just continually paying the interest/experiencing pain.

Re: Three Kinds of Good Tech Debt

#127

Post by purple_ducks » Tue, Aug 13, 2019, 9:14 PM UTC

jakozaur wrote: post #15

Tech debt is inevitable and is good as long as you keep the level of debt reasonable, so maintanance cost doesn’t sunk too much of your dev time. More good examples: 1. Technology progress: Long time ago JQuery was the best for UI library. Today you would use React or friends. 2. Company stage. As a early startup you usually prioritize for speed and validating hyphothesis. As you got a significant user base quality m…

> With 50 developers you likely take more advantage of microservice architecture so each team can be decoupled and move faster.

Microservices aren't magic. There still has to be a contract between the services. Microservices are best when they are something which need to be scaled independently of the rest of the system.

Re: Three Kinds of Good Tech Debt

#128

Post by RangerScience » Tue, Aug 13, 2019, 9:22 PM UTC

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…

"Crap is OK until you build on top of it. Then you need to clean it up."

Re: Three Kinds of Good Tech Debt

#129

Post by RangerScience » Tue, Aug 13, 2019, 9:23 PM UTC

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…

Encapsulation shouldn't be used to make it OK to remove something later; it should be used to make it OK to replace that thing later.

Then your hacky solution goes on the inside, as inline code, and then it's no problem to delete it.

Re: Three Kinds of Good Tech Debt

#130

Post by mobjack » Tue, Aug 13, 2019, 10:32 PM UTC

tziki wrote: post #106

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…

A big part of technical debt is that often... you just don't have to pay. This is what makes the comparison to financial debt a very poor one. Whenever I'm moving from one framework to another I find loads of todos I can now delete. Or even if I have a well designed class, if I can find a nice third party library that does the exact same thing, I can now get rid of all that useless code and any debt around it. Honest…

Tech debt is mainly a problem with code that needs frequent updates as it makes changes harder.

If you have messy code that doesn't need updating, then it doesn't cost a thing to leave it in a bad state. The act of refactoring in these cases is a waste of effort and often does more harm than good by introducing bugs.

I take the YAGNI when it comes to refactoring. Just pay back the stuff if the code actually slows you down in the future instead of doing it in advance.

There is a lot of tech debt you can get away with for free without ever having to pay back.