3 ms·

The problem with "tech debt" is that in the heads of non-developers it is equated with financial debt. When you take on financial debt for a business it's a lon

by danjac 4y ago

The problem with "tech debt" is that in the heads of non-developers it is equated with financial debt. When you take on financial debt for a business it's a long-term investment (a buy-to-rent mortgage on a property, or a business loan to buy a factory plant for example). So OK, we're a startup that needs to find the right market, so we'll take on X amount of tech debt to get there, and then when we are in a better place we'll pay down the tech debt in installments of X amount per month. Mostly what I've seen of "tech debt" has not been this kind of deliberate decision making of tradeoffs. It's more like: 1. Non-tech founders want to start a tech company. 2. Seeing the high salaries of developers they opt to hire their college roommate or relative. 3. Friend/relative is horribly inexperienced and builds a pile of crap. 4. Said pile of crap nevertheless gets market traction. 5. Customers complain of endless bugs & sales want long list of features. 6. Friend/relative is promoted to CTO. Time to hire experienced devs! 7. Experienced devs say "this is a pile of crap, throw it away and start over". 8. Founders tell devs no, you have to fix bugs and add features. Hop to it. 9. Developers have no leeway or political capital to fix the underlying problems, do what they can, and eventually leave. So it's more akin to an 18 year old with a gambling habit who has just discovered payday loans.

hinkley 4y ago
At some point you have to decide if integrity means knowing the right thing to do and doing it, or knowing the right thing to do and asking permission to do it. If you can’t get your coworkers on board, then they can make you look bad faster than the project will reach an intervention. If you can, you can stop having abstract conversations with managers about being Good and just start telling them that this is how long things take now. Relentless refactoring is a set of skills that are interesting but difficult enough that people lose the plot. It’s really about amortizing all difficult work across all of the work, not just the difficult bits. This is actually a strategy from real-time systems, where maximum reaction time matters, and something that XP knew and Scrum does not. A thing I’ve noticed is that there’s often a lot of gaming by management once the engineers start to say “no” but haven’t mastered yet. The bargaining is expensive in time, energy, and good will (once people realize they’re trying to trick us into doing something we said was hard by going at it sideways). When you add a day, two days, or week to all estimates, then the ratio between the smallest and largest stories decreases. The incentive to waste time trying to trick people into saying yes to something that violates the project triangle is drastically reduced. They won’t like it, but they weren’t liking anything else we tried to tell them so that’s not really a new situation. What’s new is that they see we’re serious and they don’t like it.

by danjac 4y ago

hinkley 4y ago

At some point you have to decide if integrity means knowing the right thing to do and doing it, or knowing the right thing to do and asking permission to do it. If you can’t get your coworkers on board, then they can make you look bad faster than the project will reach an intervention. If you can, you can stop having abstract conversations with managers about being Good and just start telling them that this is how long things take now. Relentless refactoring is a set of skills that are interesting but difficult enough that people lose the plot. It’s really about amortizing all difficult work across all of the work, not just the difficult bits. This is actually a strategy from real-time systems, where maximum reaction time matters, and something that XP knew and Scrum does not. A thing I’ve noticed is that there’s often a lot of gaming by management once the engineers start to say “no” but haven’t mastered yet. The bargaining is expensive in time, energy, and good will (once people realize they’re trying to trick us into doing something we said was hard by going at it sideways). When you add a day, two days, or week to all estimates, then the ratio between the smallest and largest stories decreases. The incentive to waste time trying to trick people into saying yes to something that violates the project triangle is drastically reduced. They won’t like it, but they weren’t liking anything else we tried to tell them so that’s not really a new situation. What’s new is that they see we’re serious and they don’t like it.