3 ms·
Tech Debt Friday worked for this team, good for them. It will probably not work for another team. Tech debt is never ending discussion. But ask yourself: why i
by hbrn 4y ago
Tech Debt Friday worked for this team, good for them. It will probably not work for another team.
Tech debt is never ending discussion. But ask yourself: why is almost every team struggles figuring out how much time to dedicate to tech debt? Why is there a constant tension between engineering and management?
The answer is simple: engineers and business people don't understand each other. We live in different worlds and speak different languages. You can't solve this problem with a methodology. If Tech Debt Friday or Google's 20% works for you, that's just luck (or wishful thinking).
Once you understand where the problem is coming from, the solution is also simple: find someone who speaks both languages and trust them to decide. Typically that person is a product engineer: it's easier to explain business to an engineer than engineering to a business person.
And when I say trust, I mean both engineering and management should do it. I.e. if that person says a couple of outages is not a big deal, it's not a big deal. If that person says we need to spend next week refactoring, then that's what you spend your next week on. Obviously you can still challenge those decisions, but you have to accept that this person is an expert in their domain. They don't know everything, but they know more than you. Even if you're the CEO. Even if you're coming from FAANG with 20 years of experience.
That's why companies where founder is a product engineer typically don't have a tech debt problem (they still have tech debt, they just don't have a problem with it).
I know it sucks to not have a mathematical or managerial solution to tech debt, but the tech debt is inherently complex and humane. Tech debt happens when humans are solving problems for other humans. The only solution to it is to have another human in between. The quality of that solution will depend on the quality of that human. It's not going to be perfect. But it's the best you can do.
All other approaches are just shots in the dark.
- sibeliuss 4y ago> And when I say trust, I mean both engineering and management should do it. I.e. if that person says a couple of outages is not a big deal, it's not a big deal. If that person says we need to spend next week refactoring, then that's what you spend your next week on. Obviously you can still challenge those decisions, but you have to accept that this person is an expert in their domain. This is certainly the answer to this problem!
- Nomentatus 4y ago"find someone who speaks both languages and trust them to decide" This is ideal. But finding code monkeys that can also tapdance isn't trivial. For some companies, it isn't possible; or HR won't pay the price to hire them. Sometimes management wildly overestimates their technical chops and won't tolerate "bilingual" middle managers because such people are constantly advertently or inadvertently reminding top management of their actual lack of technical knowledge. So this is where the Fridays scheme comes in; it requires you to gain that trust once, for the one day a week of self-directed work. You might still be able to do that. It also helps prevent dev team "tunnelling." The author makes clear at the very end of the article that in some companies, even the amount of trust nec to pry loose one day a week can't be obtained, and the Friday scheme won't work.