81–90 of 198 posts
One cost of accruing tech debt is the toll that it has on the mental health of developers. To me, it seems like common sense that over a certain threshold, unhappy developers will (1) work slower, (2) produce lower quality work, and (3) have a higher rate of turnover. I’m curious if there is any research on this effect (if it exists).
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…
If their budget allows for that, then okay we go ahead.
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…
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…
I don't know about you but that is typically not at all how things go at my job.
I can present a 3 week estimate to manager, he will say why 3, seems like it should be easy??, Bob says it would take 2, can you provide a breakdown of the estimate, why does estimate have 3 days for "unforeseen obstacles"?, let's cut that out. We only have 2 weeks but we can't cut scope. 1 year later everything takes twice as long as it would in a cleaner design, management is wondering why dev productivity is low and won't allocate time to maintenance (we can't spend even MORE time on some refactor thingamajig, our productivity is already low!!). Meanwhile im trying to figure out some monstrosity of a codebase written by an engineer who left last year, and also neglected to document their code (unfortunately their manager felt 1 day for documentation was unnecessary). I think this is closer to the scenario most devs operate in. In all but the best high trust scenarios, every estimate is a negotiation.
In reality technical debt is 10% a communication problem (as this and many blogs like to frame it) and 90% a "do you trust your mechanic to have your best interests at heart" problem.
Poor software increases the length and cost of the supply chain of producing new features, or it makes the supply chain more fragile, or less flexible.
"if we invest around 3 months now then we will reduce the time to market of every subsequent feature by about 2x and also decrease the number of bugs each feature produces by about 70%"
Then make sure they understand that these are just approximate estimates, but it gets the idea and the urgency across.
Speculation ahead: One cost of accruing tech debt is the toll that it has on the mental health of developers. To me, it seems like common sense that over a certain threshold, unhappy developers will (1) work slower, (2) produce lower quality work, and (3) have a higher rate of turnover. I’m curious if there is any research on this effect (if it exists).
Business began with a certain idea, then over time pivoted into into better and better, mostly related niches for users. What that meant in terms of the code base is we started with one thing then tried to back-port it in several new directions and ended up with a gigantic ball of spaghetti.
Great job, great coworkers, great technical management. Code base just became so rotted and so overextended, it became untenable.
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…
There are always trade-offs, and a good partner in any team/business will help those be articulated.
One thing that is important for any engineering team is to have a certain amount of capacity either permanently dealing with technical debt, or regularly dealing with it. Judging the amount of effort that goes into fixing it depends entirely on the amount of 'interest' you're paying. That isn't always easy to measure, but a good senior engineering team will have a sense of when things are getting hairy.
The idea that it's avoidable is unfortunately wishful thinking for any project of a substance.
Alternatively, in companies where there are Product Managers or Engineering managers, those folks should be skilled at parsing, translating, and conveying the technical issues to management and stakeholders in financial terms they'll understand.
"We" the engineers don't sound like idiots - "we're" being literal, which is all "our" job typically requires of us. I see this as a failure of leadership rather than an individual-contributor problem.