11–20 of 198 posts
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.
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.
Not all technical debt is the same. Some things may be more aesthetic in nature. Other things more serious. Even for these more substantive problems, technical debt can usually be ignored, for a while at least. Then when it can’t, major problems can arise. This strikes me as similar to insecure code. It’s not a problem until it is a problem, then it’s a big deal. But it can be difficult to quantify the costs-benefits…
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.
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…
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.
> Companies and business leaders don’t care if jobs are hard or annoying or take longer than they “should”. The difference between a user story taking a day or 3 days is negligible compared to its business value.
And then literally two sentences later:
> They care about time to market.
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.
And yes a not that clean feature, which is easy to refactor IF you touch it again is not technical debt.
Instead lern to talk back: "oh you promised our customer that this feature will be ready tomorrow? I'm seeing a big risk in this as there are still issues we haven't figured out, you might want to manage their expectation."
"Ah sry I can't work longer today I already have a reservation"
"On the weekend? Mh I booked a hotel already"
"How long this takes? Mh let's see (1 day guess + 100% risk + backupday) at least 3 days. I can get back to you in 2 days to give you an update."
"I can prioritize your new request but I will talk to x to tell him that his task will be delayed."
"Didn't you promise customer x feature y already? Should I stop working on y to start with your new request?"
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 pick 'slow and careful', because that's not their job; their job is to quickly deliver value/outcomes/whatever.
Almost no one has a job of 'go do this really slowly and carefully'.
They will always pick fast, and it's your problem later.
So... don't do that. Instead, say: this is how long it will take to do.
Not "if we rush we could probably do it in..."; no, if you say that, then why are you not rushing now? Do you not care what the business wants? Do you not have 'skin in the game'?
Say: This is how long it will take, we estimate. If you want it faster, we can cut some features.
Then, do enough of a good job so you can continue to deliver value in the future.
That's literally your job.
Doing a rubbish job as quickly as you can is not your job. Not ever.
You cannot abrogate responsibility for doing your job properly by saying "but I was told to do this", if you literally gave them the choice of A or B, where one of those options was "you have to pick this one, and it lets me get away with doing a rubbish job of it".
That's YOU choosing to do a rubbish job.
...and to be fair, yeah, there are situations where someone will come and tell you "no, do it now", and that's what you have to do... but you also have to come and clean up afterwards. Not because you're told to, explicitly, because... it's your job.