Live data from Hacker News

Three Kinds of Good Tech Debt

engineering.squarespace.com

131–140 of 159 posts

Re: Three Kinds of Good Tech Debt

#131
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 don't like the metaphor. With financial debt, you get $X up front for $Y (where Y >= X) and pay $Y amount over N months. It's known up front what it's costing you (Y - X) over what time span (N). If the difference between Y-X is low, congrats! You got a great interest rate. If it's large, well, good luck!

But in both those cases, the pain is known up front. The discussion here seems to be no one knows what X is, nor Y, but it's expected that Y > X by some large amount that you may or may not have to pay off. Crazy!

Re: Three Kinds of Good Tech Debt

#132
post #112

Technical debt is a wonderful ally when building prototypes. Imagine you are building a prototype and you are clever enough to only focus on validating an idea. Having this focus you ignore all best practices and maintainability issues you might tend to out of habit. What you are likely to end up with is a functioning application that resists change beyond its original goals. And this is good. It lets you declare tec…

As long as both sides (developer, management) are aware of this (he says, as his "proof-of-concept" was installed into production directly by his manager with no warning).

Re: Three Kinds of Good Tech Debt

#133

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…

There is no difference. Regular debt is also discharged in bankruptcy.

Re: Three Kinds of Good Tech Debt

#134

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.

That's fine in a system with a small number of quick hacks. In reality, the number of quick hacks grows over time and you end up with a brittle system that has a lot of unanticipated behavior that only a few people understand how to work with. You will eventually have quick hacks that exist to fix bugs in the other quick hacks.

Re: Three Kinds of Good Tech Debt

#135
post #131
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 don't like the metaphor. With financial debt, you get $X up front for $Y (where Y >= X) and pay $Y amount over N months. It's known up front what it's costing you (Y - X) over what time span (N). If the difference between Y-X is low, congrats! You got a great interest rate. If it's large, well, good luck! But in both those cases, the pain is known up front. The discussion here seems to be no one knows what X is, no…

I disagree about the pain being known up front - you are aware of an obligation and that obligations units in dollars, but how those dollars translate into future missed opportunities is unknown... additionally you always have some risk due to currency fluctuations if you're operating an international business, if you're primarily operating in AUD and payroll is in AUD but the loan repayment is in USD then a profitable quarter may end up being much less able to pay down your debt.

I agree that money is much more comprehensible, but there isn't so as stark a difference in knownability as it might initially appear.

Re: Three Kinds of Good Tech Debt

#136

Earlier quoted context omitted.

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

I work on a product with a large amount of tech debt, and that debt was almost universally created using the methodology in your first category. Most of it is extremely well documented. That doesn't magically make it not technical debt.

Re: Three Kinds of Good Tech Debt

#137
post #136

Earlier quoted context omitted.

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

I work on a product with a large amount of tech debt, and that debt was almost universally created using the methodology in your first category. Most of it is extremely well documented. That doesn't magically make it not technical debt.

Debt implies you consciously accepted it.

What you’re describing with your product is the fruit of unskilled (amateur) labor.

Re: Three Kinds of Good Tech Debt

#138

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…

I think what you're saying is the more common use of "tech debt", basically just using it as a synonym for "bad code". Don't worry about code quality, figure it out later.

It ignores the stronger debt analogy -- sure, there is a high chance that the idea fails. But if it succeeds and, all else being equal, you have taken on a less tech debt to get there, you will be able to iterate on and grow it more efficiently. So to the extent you're taking on debt, it should be an explicit trade-off to increase your chances of proving out the idea. Which is not the same as "don't worry about bad code at all."

From what I've seen, when it comes to talking about tech debt from an early prototype, it's often an excuse/euphamism to be considerate to the people that wrote it. The truth is often that it's just bad code due to them being inexperienced or lacking the skill or discipline to write better code. Which I don't mean as an insult, it seems like there's a strong inverse correlation between the kind of person who's passionate enough about product over tech, and is creative/naive enough to build and validate a brand new product, and the kind of person who understands enough to architect a great system and make the best tech debt trade-offs.

Re: Three Kinds of Good Tech Debt

#139

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 little trickier maybe in that some tech debt is in the eye of the beholder. Some may consider an Angular UI tech debt, others might consider it an asset versus, say, React + whatever other parts it needs.

Re: Three Kinds of Good Tech Debt

#140

Earlier quoted context omitted.

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…

There is no difference. Regular debt is also discharged in bankruptcy.

But that affects your ability to borrow in future, whereas a canceled project doesn't affect your ability to write rushed code in future. Unless you get fired, I guess...
Post reply on HN