Live data from Hacker News

We sound like idiots when we talk about technical debt

cyclic.sh

51–60 of 198 posts

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

#51
post #28

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…

That's exactly how startups think, though. The king raises an army to conquer rich lands and pay off debt. The founder makes hacky products, to get users, then raises money to hire engineers.

It has to be moderated by comprehension. If a leader doesn't understand what interest rates are, they'll borrow money every time it's available. A startup needs to borrow enough to succeed, but not so much to be bankrupted by debt payments. Same for technical debt; enough to move fast, but not so much the software (or staff) collapses before revenue.

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

#52
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…

The issue is with non-technical people who see that the hacked together mess of a proof of concept "works" and insist that you can just build straight on top of that without any work to make it into an actual working codebase.

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

#53

Earlier quoted context omitted.

Features have a lot of development advantages over maintenance. Features are fun and rewarding to implement. Maintenance is boring. This seems small, but it's actually huge. Feature work can be done many times faster because of it. I got hired at my current job because people left because the feature phase was over and they didn't want to do maintenance. I'm probably going to leave because this work is simply not int…

I agree. I think people on HN generally underestimate the extent to which developers themselves push to work on new features instead of maintenance. It's often a different kind of feature though. I can't count how many times in my career devs (including me!) instantly jumped to "we need to rewrite X using new framework Y" in response to technical debt in X.

I only saw that behavior in younger devs.

The average dev just does their job. Same as with the average person in every industry.

Sure, it's nice to do a cool feature, but most people don't work at interesting projects to start with, and they simply have to churn on. There isn't much difference between a new feature or maintenance in boring projects.

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

#54
post #30

People saying "its on you" and "has your boss ever reviewed the code?" have not had varied enough experiences. Ever had your boss tell you a feature needs to be delivered next week or the business closes? Or that you're fired? I have in fact had my commits gleaned by my boss, told me "no, we're not shipping these 10 lines of code because that goes too far and not what I asked" and then refused to accept the pull requ…

It doesn't even require management to be unreasonable/intransigent/whatever. It's perfectly rational to write a prototype feature in a quick and hacky way, and then invest time in making it clean and extensible after you've validated user demand.

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

#55
post #6

Earlier quoted context omitted.

Features have a lot of development advantages over maintenance. Features are fun and rewarding to implement. Maintenance is boring. This seems small, but it's actually huge. Feature work can be done many times faster because of it. I got hired at my current job because people left because the feature phase was over and they didn't want to do maintenance. I'm probably going to leave because this work is simply not int…

I _love_ maintenance and fixing technical debt, much more than working on features.

And it's easier though if you have different skillset than feature development.

Essentially the features, flows and output are fixed and defined, so you don't need to think about that. Your skills at performance optimization, refactoring, unit testing and debugging really shines here.

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

#56
post #11
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 find I have to head check myself from having negative thoughts about approaches that I wouldn't have taken. Like seeing old java, or bootstrap :P. It still works, fixing it may make things neater, but does that really pay down debt?

Yeah, this feeling is ubiquitous among programmers (or 'developers' perhaps), and I suspect it's a large reason why businesspeople are suspicious of "we need to invest time paying down tech debt".

There's a big difference between "this code is horrific and can't be built upon" vs "ugh, this framework is so old, we need to rewrite it in Foo.js".

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

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

I like the term because it is like financial debt, and is a good way of communicating the problem to a business person. The debt will need to be paid off at some point, the longer you leave it the more that is going to cost, and it costs you even if you just keep paying the interest. Framed this way, it also helps us explain why many business people don't care. Many will only care about the projects they are currently responsible for and not about next weeks or the ongoing health of the company. With luck, paying the debt will be somebody else's problem. If you called it 'cutting corners', you get a pat on the back for keeping costs down and expected to do it more often. You might even get a bonus if your boss doesn't take the credit.

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

#58
post #38
post #37

Earlier quoted context omitted.

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.

I did not say that I'm slow due to this or not agile.

But I will not build a sync feature and not having alerting if it fails.

I will not write nee Features and will not think about a proper index.

If you do it right and actually learn those things from an early point those things become obvious.

And yes there is also that believe that a bug in production costs 10x what it would cost to find while developing.

Yes I'm aware of the fallacy that a manager might praise you if you are fast and accepts bug as a common normal thing.

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

#59
post #42
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.

It is essentially the same as financial debt, too much debt and you go bankrupt, but if you refuse to take some debt, you may lose opportunities. The main difference is that technical debt is hard to quantify. Financial debt is obvious, you see the numbers, interest rates, etc... You see how much repaying your debts will save you money. Technical debt, you know it is there, but you can't easily put a number, you don'…

It is not the same. Financial debt has to be on the balance sheet; technical debt is not. My point is the a finance/business guy will think in the totally wrong direction with what you actually mean. Also to whom do you repay technical debt?
Post reply on HN