Live data from Hacker News

We sound like idiots when we talk about technical debt

cyclic.sh

31–40 of 198 posts

Re: We sound like idiots when we talk about technical debt

#31

Usually it's hard to quantify technical debt. And anyway, when debt is first accumulated, it has no downsides. When you first take out a loan, you don't pay anything for the first month. Without understanding the long term nature of debt and interest, you will see it as free money. Business leaders have wisely learned how finances work, and financial debt. We need to learn how software engineering works, and technica…

A better term might be "technical mass". Having lots of it makes it harder to quickly implement changes and features. It would also better cover the fact that work must be done to get rid of the excess mass. Calling it debt might undersell how easy it is to get rid of it. Though if business folks didn't take physics classes it might not resonate well with them.

Technical calories then?

Re: We sound like idiots when we talk about technical debt

#32
post #19

Stop talking to business about technical debt. Stop creating technical debt. No one ever asked me why in particular something took 3 days. I don't explain to someone that I wrote unit tests and no manager told me not to write tests. Did you ever got chewed out by a manager looking through your git commits and asking you why you wrote it as it is written? If you accept technical debt it's the development teams fault.…

Sorry, but how old are you? Add the line “stop creating bugs” into this text to make it complete.

I'm 34 and work like this, successful for 12 years.

I have a min. Standard I achieve and will not compromise this standard to keep me sane.

I will not create things which will fall back to me in 3 month.

I develop slower but have to revisit things rarely.

Re: We sound like idiots when we talk about technical debt

#33
post #13

I think the term 'technical debt' is not good. It creates the wrong mindset if you talk to a business person, since they probably get into the mind frame of 'financial debt'. Why not call it 'we have been cutting corners in the software architecture'; I think people will understand that analogy better.

Investor: "If developers have debt, why don't they simply repay it? They could pay in install-ments."

Bigger question:"whom do they owe the debt to?" - "to themselves" - "oh, then just strike it off"

of course thats a silly answer: "to the code base" - "who owns the code base" - "the company" - "well then lets just get rid of that 'code base thingy'"

Re: We sound like idiots when we talk about technical debt

#34
post #19

Stop talking to business about technical debt. Stop creating technical debt. No one ever asked me why in particular something took 3 days. I don't explain to someone that I wrote unit tests and no manager told me not to write tests. Did you ever got chewed out by a manager looking through your git commits and asking you why you wrote it as it is written? If you accept technical debt it's the development teams fault.…

Agreed. But what is "Mh"?

It's a written sound like hmmm humming

Re: We sound like idiots when we talk about technical debt

#35
post #3

Technical debt and its costs are extremely hard to quantify and saying things like "with 3-6 weeks of engineering time we can cut failures in half" is just inventing numbers to get what you want.

I had a conversation that stuck with me a few years ago at a very large company about making proposals for future projects. I had a habit of making very detailed proposals, doing a great job making projections and being accurate about those projections.

A VP of engineering pulled me aside after he saw that one of my proposals wasn’t getting traction and told me “None of the people who are writing alternatives to your proposal are doing the analysis you are, that’s why they look better than yours”

I guess I had never considered that a lot of my peers were just inventing numbers to justify things they wanted and that there’s a careful balance that needs to be struck between “making shit up” and “detailed unbiased analysis”

Re: We sound like idiots when we talk about technical debt

#36

Controversial idea: Technical debt is something that 'business users' don't need to or want to care about. If you're having conversations about technical debt, you've messed up, and you will continue to have unsatisfactory outcomes until you stop doing so. You can't tell people; here is a dial, you can pick 'fast and you're screwed later' or 'slow and careful now'. You're setting yourself up for failure; they cannot…

Sometimes you just need to deliver quickly and cutting scope isn't an option.

Sure you can say that it's not possible. Then you get replaced by someone who's willing to take the necessary shortcuts.

What's important is to make it clear that you're taking shortcuts and that you will need time allocated to clean it up later. That's basically what technical debt is.

Re: We sound like idiots when we talk about technical debt

#37
post #24
post #19

Stop talking to business about technical debt. Stop creating technical debt. No one ever asked me why in particular something took 3 days. I don't explain to someone that I wrote unit tests and no manager told me not to write tests. Did you ever got chewed out by a manager looking through your git commits and asking you why you wrote it as it is written? If you accept technical debt it's the development teams fault.…

The point of technical debt is that you don't want to invest an amount of time appropriate for [long-term business-critical feature which will be built upon] into something which is currently [basic experimental feature which may well be ditched]. When the latter is validated and becomes the former, that's when - and why - you repay your tech debt. A team that builds everything as though it were a business-critical f…

I'm not writing prototype Software.

Everything will find its way back to you.

Bugs are very costly.

I always make sure I für understand what the problem is. This can lead to me having discussions of 2-3 h and the outcome is that we actually don't need it. Or that we reduce the scope to deliver on time.

I'm not aware of things I write which will not bite me back one way or the other if I'm doing it shitty and having development standards is not developing a rocket.

Re: We sound like idiots when we talk about technical debt

#38
post #37
post #24

Earlier quoted context omitted.

The point of technical debt is that you don't want to invest an amount of time appropriate for [long-term business-critical feature which will be built upon] into something which is currently [basic experimental feature which may well be ditched]. When the latter is validated and becomes the former, that's when - and why - you repay your tech debt. A team that builds everything as though it were a business-critical f…

I'm not writing prototype Software. Everything will find its way back to you. Bugs are very costly. I always make sure I für understand what the problem is. This can lead to me having discussions of 2-3 h and the outcome is that we actually don't need it. Or that we reduce the scope to deliver on time. I'm not aware of things I write which will not bite me back one way or the other if I'm doing it shitty and having d…

Well, that seems like a wasteful amount of time to spend on prototype products or functionality. It's up to you if you want to do that, but other people will likely out-manoeuvre you by being agile enough to iterate quickly.

Re: We sound like idiots when we talk about technical debt

#39
post #19

Stop talking to business about technical debt. Stop creating technical debt. No one ever asked me why in particular something took 3 days. I don't explain to someone that I wrote unit tests and no manager told me not to write tests. Did you ever got chewed out by a manager looking through your git commits and asking you why you wrote it as it is written? If you accept technical debt it's the development teams fault.…

There's (at least) three causes of technical debt that aren't due to engineering negligence (but I agree in general that many sources of "technical debt" are self-inflicted):

1. Domain modeling shifts. Engineers get a sample of the business rules for the domain they're trying to model every time they build a feature, but it's an incomplete picture. And in fact sometimes the very nature of what the business is trying to accomplish changes. That can require fundamental shifts in how the problem is modeled.

2. Changes of scale. What was engineered to support 10,000 MAU will not necessarily tolerate 100M MAU. Scale can be insidious for tech debt because it's often a slower creep of a problem w/ a high cliff in the amount of effort required to solve for it.

3. Planning/communication failures. Sometimes a critical aspect of a feature is not fully understood or articulated. Or an important delivery date for a promise is overlooked. Depending on the nature of the company's business, an early stage company often doesn't have a choice but to deliver on things that weren't properly scheduled.

Re: We sound like idiots when we talk about technical debt

#40
post #17

The metric that you use to measure technical debt is "the time it takes to build new features over time". If that line on your graph is going up, you have a problem.

I somewhat agree, but every feature is not equal. And you usually start with the easy ones... So, even without any technical debt, it will probably go up, just less fast.
Post reply on HN