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

91–100 of 159 posts

Re: Three Kinds of Good Tech Debt

#91

Post by gmueckl »

jamie_ca wrote: post #75
gmueckl wrote: post #31

Earlier quoted context omitted.

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 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 later when you have the still unquantified extra overhead of not breaking stuff that has been built around the insufficient solution.

Re: Three Kinds of Good Tech Debt

#92

Post by skybrian »

wellpast wrote: post #80
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.

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

Re: Three Kinds of Good Tech Debt

#93

Post by skybrian »

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…

That is actually the point of the metaphor. Taking on debt without a clear business reason is supposed to sound bad.

Re: Three Kinds of Good Tech Debt

#94

Post by shkkmo »

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…

> by the time this happens, the assumptions underlying the shortcut have implicitly been taken on by the code depending on it.

If this has happened, your encapsulation was insufficient or you waited too long to replace the stop gap solution or maybe your documentation wasn't clear about what assumptions made by the throwaway component are safe to make in the main codebase.

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

I think the article's description of when stopgap solutions should be used is far better. Yes, a leaf feature is likely to have fewer encapsulation issues, but that is only part of it.

Re: Three Kinds of Good Tech Debt

#95

Post by vinay_ys »

wellpast wrote: post #30

I'm going to take a more controversial position here, and it bothers me that it is even controversial. The very concept of Tech Debt, though prevalent, is pernicious, because its a concept that is far, far, far too fuzzy and therefore can -- and is -- always applied as a convenient narrative to explain away mistakes, process deficiencies, bugs, etc rather than a true conceptual problem-solving tool that aids in optim…

I think you are being overly harsh. Since you seem to take issue with the term tech debt as a fuzzy term, I suggest you read up on the research on this matter (Researchers talks and paper published by https://sei.cmu.edu is a good starting point).

A developer aiming for technical supremacy for its own sake isn't useful in a real-world business scenario. I've seen enough technically superior software products utterly fail in the market due to poor product-market fit iteration speed.

Tech debt isn't a choice an individual developer should make. Tech leaders at the top of any evolving software based product/service should deeply understand the pros and cons of the concept of tech debt and then decide to use it as a strategy lever.

They will have to make appropriate choices w.r.t people and process that is right for their company to leverage tech debt.

This will reflect in the technical architecture of the systems as well. There will be different layers of the stack where tech debt can be more vs less.

There are automated measure that can keep you informed if the tech debt is exceeding to the point where it is becoming a net liability (vs being a net asset as a strategic lever).

It may be true that many organizations use the term tech debt very fuzzily and don't really give it conscious and serious thought and put effort to structurally leverage it. In this, your rage against may be justified.

For those who are interested to read more on tech debt should visit these links:

https://martinfowler.com/bliki/DesignStaminaHypothesis.html

https://martinfowler.com/bliki/TechnicalDebtQuadrant.html

https://2019.techdebtconf.org

Re: Three Kinds of Good Tech Debt

#96

Post by opportune »

I think that "Good Tech Debt Is Intentional" is the key point. If you are able to recognize something as technical debt as it is created, you can also more effectively plan for paying it down later, and note what you think the solution would be at a high level. The real issue with tech debt is not that it exists, but that people wait too long to pay it down, and then end up taking more dependencies/making more technically bad decisions to deal with the tech debt which just makes it even harder to fix.

Re: Three Kinds of Good Tech Debt

#97

Post by aeorgnoieang »

wellpast wrote: post #80
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.

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

Re: Three Kinds of Good Tech Debt

#98

Post by devonkim »

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?

Bankruptcy is more correctly letting you get away from obligations to creditors with lesser terms to the creditors than originally agreed because you can no longer pay it back. I think there’s nothing very close to this for technical debt because even in a rewrite there’s new debt involved. A rewrite is a lot closer to refinancing where the value of the asset is re-evaluated and new terms of debt repayment are structured that stakeholders agree to. Most people seem familiar with chapter 7 bankruptcies but there’s 11 and 13 too. Furthermore, bankruptcy is about handling an original amount lended - rewrites oftentimes are done with lessons learned from the original version (rewriting from Python to Go isn’t bankruptcy).

Technical debt bankruptcy is probably closer to shutting down a service / product with no replacement - the effort has already been spent and you’re walking away from costs without caring for the creditors (customers and engineers alike).

The question of whether technical debt can be zeroed in a technical bankruptcy is who the creditors of technical debt really are - is it the business as a whole or the engineers that maintain this stuff?

To me, the state of technical debt bankruptcy is a business in a zombie state unable to grow to service the debts because of the technical debts keeping them uncompetitive rather than something more fundamentally wrong with the business like product market fit or bad reputation.

Re: Three Kinds of Good Tech Debt

#99

Post by arugulum »

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?

The key part analogy isn't bankruptcy so much as interest. You incur technical debt and you pay it off later in interest (by spending time to clean up the hacky code). If you don't pay off the interest, you end up incurring even more technical debt. Eventually, you could end up paying several times more in interest than the principal (end up spending more time working around the hacky code than if you've just addressed the issue properly in the first place).

Re: Three Kinds of Good Tech Debt

#100

Post by jdance »

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 topic -- this is the worst wasted time debt Squarespace has to me as a customer :) code wise the product is really solid so their philosophy is obviously good!

Post reply on HN