Live data from Hacker News

Three Kinds of Good Tech Debt

engineering.squarespace.com

41–50 of 159 posts

Re: Three Kinds of Good Tech Debt

#41

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.

But that's the point. It is a fuzzy thing. Software is built on business priorities, not technical ones. These align a decent amount of the time. Spending the extra time and money to set up tests is very much worth it.

Is it worth implementing a cache layer in a system? One on hand, you have a better system that can handle more load, on the other, you've spent time that could be spent doing something else. Your systems will almost always have limitations, it's important to understand these and communicate them well. Tech debt should be managed so it doesn't tip over and cause issues. Really good devs and dev managers develop the eye to see when that's about to happen and make sure they convince product that you need to pay that down soon.

Re: Three Kinds of Good Tech Debt

#42

As I’ve gotten more senior in my career, I think one of the most enlightening things has been anticipating debt before it happens (in planning/architecting), acknowledging it when it does and then taking prudent measures to minimize it and log it for future refactoring. It’s also been funny seeing managers try to rebrand tech debt with other business speak like “tech health”. Debt shouldn’t be a bad thing but one tha…

I've also come to realise that technical debt is everything. Anything that is resistant to change is technical debt, which includes the code you are writing "now", whether you anticipate its need to change in the future or not. There's the stuff that you know is painful or messy, but then there's the stuff that is suitable for today's needs but those needs may change in the future. Nothing is free from debt.

Re: Three Kinds of Good Tech Debt

#43

Earlier quoted context omitted.

> I find developers tend to really dislike throw away code or temporary solutions This is good way to level up: Learn to love throwing your code away!

Maybe programmers need to listen to Marie Kondo more.

does this for loop make me happy?

Re: Three Kinds of Good Tech Debt

#44

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…

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.

Re: Three Kinds of Good Tech Debt

#45

Earlier quoted context omitted.

> I find developers tend to really dislike throw away code or temporary solutions This is good way to level up: Learn to love throwing your code away!

Maybe programmers need to listen to Marie Kondo more.

"Does this code bring me joy?" :P

Re: Three Kinds of Good Tech Debt

#47
@1: One could also have automated tests instead of scaffolding.

@2: Sure, but this it not really technical debt. It is the wise policy of not immediately writing code for the most general case. If one writes several instances of this it would lead to code duplication that would need to be refactored immediately.

@3: Careful with this one. The thing is that the thing you call an edge case might have the more proper name of 'bug'. If you deliberately leave in bugs at the time of writing the code it can lead to very difficult to estimate 'stabilization time' at the point where the code is supposed to go into production but is not quite reliable enough. It becomes somewhat difficult to explain if that 'stabilization time' turns out to be months or even as much as a year.

Re: Three Kinds of Good Tech Debt

#48
The defining characteristic of technical debt is attempting to avoid paying it, taking shortcuts that create "interest" in the form of increased effort and cost; it's always bad, but depending on timing and costs it can range from a "correct" minimum cost choice (e.g. badly tested truly throwaway code) to a stupid mistake to an existential threat.

Technical debt is a close relative of externalization (I save time, you waste time) and of mistakes that result from incompetence rather than from haste and shortsightedness.

All three sections of the article, instead, describe healthy planned evolution from a decent provisional product to a better one, with solutions that might be rough but not necessarily bad. In other words, a clickbait title for sound (but maybe unrealistically mature) examples of properly pragmatic project and product planning.

Re: Three Kinds of Good Tech Debt

#49

Earlier quoted context omitted.

> while you can pay off debts by taking on other debts, there is a good reason why this is illegal Loan consolidation is quite normal in the UK

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?

In business/commercial lending the purpose of the loan is typically a part of the contract. You can’t say you will use the money to buy equipment and then use it to pay off another debt. Also you will have to provide regular (yearly/quarterly) financial statements (typically audited) that include a balance sheet that would list all outstanding debts and assets. As long as you abide by all your existing and future loan covenants you certainly can use loans to pay off debt and many people do. When you can’t it’s due to contracts, not “laws”.

Re: Three Kinds of Good Tech Debt

#50

Earlier quoted context omitted.

The term "debt" is really helpful. It also explains that while you can pay off debts by taking on other debts, there is a good reason why this is illegal (if done with money) in the real world. Technical debt in your solution is fine. Running a Ponzi scheme in your solution isn't.

> there is a good reason why this is illegal (if done with money) in the real world. Erm, it very much isn't illegal. At least not in most places. Taking on fresh debt to pay off other debt is the very definition of a consolidation loan which is perfectly legal in most, possibly all, jurisdictions. There are limits of course, like not using a loan to pay the deposit on a mortgage, or simply not lending beyond defined…

also basically any 'balance transfer' option on pretty much every credit card ever.
Post reply on HN