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.
We sound like idiots when we talk about technical debt
51–60 of 198 posts
Re: We sound like idiots when we talk about technical debt
#52Stop 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…
Re: We sound like idiots when we talk about technical debt
#53Earlier 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.
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
#54People 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…
Re: We sound like idiots when we talk about technical debt
#55Earlier 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.
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
#56Technical 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?
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
#57I 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.
Re: We sound like idiots when we talk about technical debt
#58Earlier 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.
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
#59I 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'…