4 ms·

Thanks for sharing your perspective. Some fun sprinkles of complications > and my team's velocity is badly bogged down by some tech debt, then the right alloca

Thanks for sharing your perspective. Some fun sprinkles of complications > and my team's velocity is badly bogged down by some tech debt, then the right allocation to fixing it is 100% (fix the shit so we can go fast forever.) That's impossible. Software, like all things in nature, evolves and degrades over time and there is unlikely a magic 100% fix. Something can always be improved. > On the other hand, if some "tech debt" doesn't actually impact team velocity/clients (eg, some code is "bad" but it's in a part of the system that's never touched) the right allocation is 0%. Tech debt is also a great way to get your executing development team down to 0%. Yes, some people leave organizations because the code quality is bad and no one cares to improve it and it makes everything just a tad worse. This can compound over time. One day, the thing that is never touched will need to be touched and no one will be able to understand it in a timely manner, leading to other failures and re-prioritization. > The X% approach seems to happen when engineering and product fail to have that conversation, fail to understand each other, so they have to just get a flat allocation each. Agreed, a constant conversation is a good starting point but eventually, there will always be a bias in one direction. As you demonstrated, your bias is "There's ultimately the only thing that matters - getting value out to the customers". This makes you more likely over time to prioritize shipping to the customer over invisible improvements. The feedback loop continues until things breakdown. If you're in doubt, go ask your EM/TL partners if there isn't some technical debt they think is more important to address in the next 3 months than whatever you're currently trying to ship. Technology organizations are quite complex systems but i appreciate your attempt at simplifying.

xyzelement 4y ago
I agree with your worries and that feeds into my system of thinking. For example: // One day, the thing that is never touched will need to be touched I would categorize that as a potential risk to the thing that matters (customer delivery over time.) So the conversation that should be had then isn't "module X is written in a bad way" but "we're down to the last person who knows module X, if he leaves and we need to change it, we're screwed. Are we willing to tolerate this risk?" (the answer may be yes or no, but expressing it in terms of impact on client delivery is more accurate than just tech debt) // Something can always be improved. Yup, similarly to how you can always decorate your house better, buy a more fully-featured car, etc. The question is should it be improved, at the cost of whatever else you can be doing? // If you're in doubt, go ask your EM/TL partners if there isn't some technical debt they think is more important to address in the next 3 months than whatever you're currently trying to ship. That's exactly the conversation I want to have. Because if they are right, I want to be persuaded so I can advocate for that investment. But if they are wrong, I want to persuade them that whoever we're doing IS more important, so we can focus on that. // As you demonstrated, your bias is "There's ultimately the only thing that matters - getting value out to the customers". That is my bias indeed. Sometimes this bias causes me to ask my engineers to fix non-functional things when they are charging ahead to do features - it cuts both ways.

xyzelement 4y ago

I agree with your worries and that feeds into my system of thinking. For example: // One day, the thing that is never touched will need to be touched I would categorize that as a potential risk to the thing that matters (customer delivery over time.) So the conversation that should be had then isn't "module X is written in a bad way" but "we're down to the last person who knows module X, if he leaves and we need to change it, we're screwed. Are we willing to tolerate this risk?" (the answer may be yes or no, but expressing it in terms of impact on client delivery is more accurate than just tech debt) // Something can always be improved. Yup, similarly to how you can always decorate your house better, buy a more fully-featured car, etc. The question is should it be improved, at the cost of whatever else you can be doing? // If you're in doubt, go ask your EM/TL partners if there isn't some technical debt they think is more important to address in the next 3 months than whatever you're currently trying to ship. That's exactly the conversation I want to have. Because if they are right, I want to be persuaded so I can advocate for that investment. But if they are wrong, I want to persuade them that whoever we're doing IS more important, so we can focus on that. // As you demonstrated, your bias is "There's ultimately the only thing that matters - getting value out to the customers". That is my bias indeed. Sometimes this bias causes me to ask my engineers to fix non-functional things when they are charging ahead to do features - it cuts both ways.