Earlier quoted context omitted.
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 .
For sure! And most of the time I would say spending 20x the time on a thing that you have no flipping idea is going to land is worse than technical debt, its called closing your doors. I just wanted to call out the posters who blame individual eng for the product quality, they've either never worked in a toxic org or are helping be the source!
We sound like idiots when we talk about technical debt
111–120 of 198 posts
Re: We sound like idiots when we talk about technical debt
#112If the contractor finds asbestos, he's allowed to quote me more to do the work I hired him for. If my mechanic says my car has old parts not in inventory, they may cost more and take longer to replace or maybe they charge more to do the work. When the laws change, your lawyer gets billed to review and update your contracts. As new legal precedents are formed, new legalese is created and updated and contracts are rene…
- If the contractor finds asbestos *which was put in by the contractor himself because using asbestos was legal (and cheaper) up to 2 years ago"...
- If the mechanic that sold me my previously owned car without telling me that servicing would be more expensive in the future...
- If the lawyer who was originally part of the team that helped draft the old law...
etc.
Re: We sound like idiots when we talk about technical debt
#113Controversial 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…
You'd better have Nostradamus-level prediction accuracy if you're going to play chicken like that with every estimate you're pressured to give.
Re: We sound like idiots when we talk about technical debt
#114Controversial 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…
That sounds a little crazy. If you applied this same argument to money, you'd conclude that their job is to spend money as fast as possible in order to deliver value, and the debt that builds up is accounting's problem, not theirs. No successful business works like this, so clearly the logic does work if it's presented correctly.
Re: We sound like idiots when we talk about technical debt
#115Earlier quoted context omitted.
To be fair, as we are aiming to become better software engineers, on every PR we make, we should be aiming to decrease our bug rate, and increase our speed, testing, robustness, performance and the overall expressiveness. Why don't you "simply write code faster with fewer bugs" seems sarcastic or unrealistic (or Übermensch) but over time with practice we should attempt to do this. And I do see it, within the practice…
I'd agree with this, but this is orthogonal to tech debt IMO. Tech debt is a trade-off of a simpler / less extensible implementation in exchange for faster product / business validation of experimental (in some sense) code. It doesn't matter how fast the individual developer is: all that matters is that, where T is some arbitrary unit of execution speed, the simple solution takes e.g. 1T and the more future-proofed s…
And that's just not so. It doesn't matter how fast or quick-minded the engineer is in absolute terms. I've worked with some of the best engineers in the world, and they still took on tech debt (albeit in an intelligent and considered way), because simpler solutions are still faster in relative terms.
Tech debt will forever be a rational choice so long as there's a comparative advantage - so to speak - in taking the simpler path.
Re: We sound like idiots when we talk about technical debt
#1161. Technical founder-led companies which have enough technical understanding to have a realistic conversation with engineering leaders and make a decision as to how to approach the problem space to balance time to market vs quality of abstractions.
2. Developers with high autonomy who can set their own timelines as long as features are delivered in expected form. In this case, the timeline can simply encompass either resolving previous technical debt or be extended so that there is enough problem analysis time to prevent the accrual of technical debt in the first place, as long as the feature works as expected at the end, but it's on the developer to deliver to expectations that may not be fully defined. These are usually organizations where engineering has high political capital as department, but the larger business treats it as high magic.
Re: We sound like idiots when we talk about technical debt
#117Controversial 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…
One thing missing from your statement is that plenty of technical-debt comes from things that were done properly the first time , but since then assumptions have changed, or the business is different, or the customer's expectations have evolved, or a competitor has upped their game, etc. This makes the so called perfect solution then, imperfect now - i.e. technical debt. There are always trade-offs, and a good partne…
Hilarious. In the IT department(s) of my Fortune 150, they still do picture-perfect waterfall development, with outsourced teams, writing Java. The application is set in stone when it is signed off in production. Things change? NEW PROJECT. Another 3 YEAR CONTRACT please.
And, yes, as as matter of fact, it IS utterly maddening to be one of the few people who bother to try to say things could be different, and watching nothing change, because so many people's jobs are literally built on their world working this way.
Re: We sound like idiots when we talk about technical debt
#118Earlier quoted context omitted.
We were talking about another topic. “Temporary dirty MVPs” are only acceptable if their code will be completely thrown away. Otherwise, “there is nothing more permanent than temporary patches” (c) forgot who.
Yeah, certainly the tech debt code should be thrown away. I think this is hard to discuss without a concrete example in mind, though. Or rather without both having the same concrete example in mind . I get the sense that everyone here is imagining their own - very different - concrete example of tech debt, and talking entirely at cross purposes as a result.
Re: We sound like idiots when we talk about technical debt
#119If the contractor finds asbestos, he's allowed to quote me more to do the work I hired him for. If my mechanic says my car has old parts not in inventory, they may cost more and take longer to replace or maybe they charge more to do the work. When the laws change, your lawyer gets billed to review and update your contracts. As new legal precedents are formed, new legalese is created and updated and contracts are rene…
I am not sure that your metaphors actually work when talking about "Technical Debt" in the IT sense of the word. - If the contractor finds asbestos *which was put in by the contractor himself because using asbestos was legal (and cheaper) up to 2 years ago"... - If the mechanic that sold me my previously owned car without telling me that servicing would be more expensive in the future... - If the lawyer who was origi…
- a developer takes a certain strategy that is no longer valid (even technical debt that isn't recognized early on as being something that will have to be changed more than likely soon, is still technical debt in my mind -- your ability to recognize technical debt early on just means you know you're incurring it)
- developers often incur technical debt without explaining to stakeholders about it because a) they don't care b) they don't think the stakeholders care c) they want to get the work done and not get dinged
- developers who have to pay for technical debt may be the creators of that debt to begin with...(of course, I'd wager that most technical debt is handled by someone else who comes later because I'm rarely given the chance to fix problems I created, project managers can be judgmental like that - and project managers have to be convinced that we can just apply some more duct tape)
Re: We sound like idiots when we talk about technical debt
#120Controversial 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 because it's disconnected from reality. You're putting ALL the responsibility on devs as if they are free to present any estimate they like that will then be then accepted without questions or negotation by management. In this fantasy land management is presumably operating in a vacuum with no pressure from customer deadlines, costs, investors, long term product roadmaps etc. I don't know about you but…