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

51–60 of 159 posts

Re: Three Kinds of Good Tech Debt

#51

Post by weego »

enginaar wrote: post #33

I'm failing to see the point in calling a technical dept "good". As far as I can tell from the article, the author is measuring 2 possibilities of technical dept and choosing the one that incurs the least dept. I can see how good a decision this is but I don't see how this makes the dept good.

Technical debt is a luxury companies with an excess of resources have. Startups without an excess of resources do not have technical debt in that, if you have no more runway and shutter thr business all you have is a bunch of code that didn't justify its own existence. By definition it is a positive situation to be in.

So code that you can propose may be technical dept that make your Series A is good debt.

Re: Three Kinds of Good Tech Debt

#52

Post by stcredzero »

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…

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.

I worked at a company where there was an API and an explicit place for such hack code, for consultants to customize the product. The way it was done, was to ensure such code was a pure leaf.

Re: Three Kinds of Good Tech Debt

#53

Post by erikpukinskis »

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…

I like that delineation between branches and leaves. If it’s a branch, solve the real problem. If it’s a leaf, consider just getting it done.

Re: Three Kinds of Good Tech Debt

#54

Post by kevinwang »

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.

What does it mean, then?

Re: Three Kinds of Good Tech Debt

#55

Post by erikpukinskis »

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.

I’m not sure how you can have such a strong no reaction to a statement that can mean almost anything.

The word “component” barely means anything at all. Lots of room for interpretation there.

Re: Three Kinds of Good Tech Debt

#58

Post by stcredzero »

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…

> Not Fixing All the Edge Cases

This can also be a part of tackling very complex tasks. To prevent getting overwhelmed when implementing something huge, I sometimes do what I call, "Implementing something stupid." Want to build an MMO? Build something that manages to send sync information to a multiple clients, but ignores auth, security, being cheat-proof, robustness, etc... Then once there's something running, start addressing those issues.

So instead of not fixing all the edge cases, it's not implementing all the edge cases all at once.

If the quick hack is well documented, written in a very encapsulated and removable way, who cares about removing it later.

When it starts causing "lava flow" then it's time to remove it.

http://antipatterns.com/lavaflow.htm

Re: Three Kinds of Good Tech Debt

#59

Post by davnicwil »

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 time and get something shipped, knowing that it will cost you more time than you're saving now to fix it later. But by shipping now, you ensure there is a later, with a product that's out there and being used, a bigger team and therefore adequate time and then some to fix the debt and keep improving the product. Everyone wins.

That's the theory anyway. I think mostly where it goes awry in the wild is people forgetting the paying it off part. Part of this deal is you have to pay back your lender - they have to win too. It's just easily forgotten because you're the lender, so the incentives get a bit conflicted, and you'll keep giving yourself more time. But if the lender ultimitely doesn't get paid back and loses, you lose, and it's a bad debt.

Re: Three Kinds of Good Tech Debt

#60

Post by matchagaucho »

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…

Ward Cunningham, who coined the term "Technical Debt", would often use the analogy "If you borrowed $500K for a house that is now worth $1M..."
Post reply on HN