This feels like it's probably dependent on the culture in question. Writing tests, caring about readability and the long term sustainability of the codebase and even managing the technical debt all can be the exceptions themselves in certain teams.
Sure, you can turn around and run for the hills, but for many there, those are the circumstances that they put up with to get food on the table, or work with for different reasons, so those circumstances shouldn't be ignored.
Ergo:
> a) refusing to put debt in to begin with
Management: "Hey, what is this ticket taking so long to complete? Can't you just develop the solution more quickly, without spending so much time on refactoring, planning or whatever it is that you do? Developer X did something similar faster just last week!"
> b) for any new work, including necessary cleanup of what you'll be touching in the estimates
Management: "Why are you suggesting estimates that are 1.5x - 2x higher than the rest of the team? Refactoring? Integration tests? Test data generation? Logging? Do you really think that those are necessary for this many tickets? Don't you want to reconsider your estimate, not to be the outlier? No? Okay, we'll just take the averaged estimate of them all."
Personally, i believe that developers should be trusted more and just care about the long term sustainability of what they're developing beyond their probably employment duration at the company (given how popular job hopping is nowadays), yet sadly that's not been the reality in my experience, probably because of prioritizing functionality and business value now, rather than stability and reliability later.
In the end, developers have to decide if they're professionals or not. Me, I think of myself like a doctor or a lawyer or an engineer. That means I have a code of ethics and professional duties. As an example, the IEEE/ACM software code of ethics is here: https://ethics.acm.org/code-of-ethics/software-engineering-c...
It's also reasonable if people think of themselves like a minion or a servant, where they're going to do what the boss says, no matter how dumb, dangerous, or counterproductive is. In which case, sure, they can excuse themselves from this discussion of how to manage tech debt, because they've decided to put that power in the hands of others.
But if they are professionals, then this indicates a good place to start:
> Why are you suggesting estimates that are 1.5x - 2x higher than the rest of the team?
Any improvement in working conditions is best achieved through collective action. That is a great moment to talk to team members about setting joint standards for estimates. And one doesn't have to approach it from a highfalutin' perspective of ethics. If colleagues lowball estimates out of ignorance or while seeking glory, that means they're just screwing over the rest of the people on their team.
Which leads me to this:
> those are the circumstances that they put up with to get food on the table
This week, sure. Not everybody can just walk out the door this moment. But over the next 5 years? Every single working developer can have a plan to get more autonomy and better working conditions. Including by building up enough of a cash buffer that they aren't one disagreement with the boss away from not being able to put food on the table.
Indeed, I think it's vital that they do. If they instead just bump along at a job with outdated tech and high debt levels, how easy do they think it will be to get jobs later in life? The skills and habits one builds while working in that sort of swamp don't look great in interviews.
I worked in a team that had great culture in this regard. Writing tests, code review, and refactoring were considered an inseparable part of every task; when you estimated the task, you estimated how much this all together would take. The task was considered complete when the comments in code review were fully addressed.
This worked well while we had a manager who was not a developer. He asked for estimates, we gave them, we delivered a product in much higher quality than was typical in the company, he was happy.
Then we got a manager who was also a part-time developer (for another team). And he started asking questions like: "Why did you guys estimate this task to take two days? I could write it in 20 lines of code, why should writing 20 lines of code take two days?" "Well, we also need to consider this, and then we need to write a unit test for this and a unit test for that, and..." "No guys, you don't. Do not overcomplicate things, just do the simplest thing that works." -- I don't know what happened with the project later, because gradually all the original team members have quit.
So, there are ways to address technical debt, and some of them do not require involving the management in too much details, but you still need some minimal level of cooperation from the management; at least on the level of "if the results are consistently ok, I will not needlessly interfere with the details just because I can".
If it's in the codebase for a single project, then sure, you can do some refactoring while you work, add more tests, etc. It's not too big of a time sink if you do a little at a time, and you can do it all by yourself.
But if the tech debt is in the architecture, or the API spec, or the authentication layer, or in some other area that impacts how services owned by multiple teams communicate? Now you need coordination with other teams to fix the debt. Everyone else has their own jobs to do, and if leadership doesn't make fixing tech debt a priority, other work will always take precedence.
I agree that if a mess is particular large, or cleaning it up will have product/schedule impact, sure, the you have to talk with the product people. But the converse it true: if you can find ways to do the necessary technical stuff while still producing sufficient business value, then the product people will never notice.
Coordinating teams does make it difficult though.
My experience has been that, once in a while, even this is not enough. You might just get accused of being a perfectionist or being overly meticulous about things that don't matter, and why can't we just do it the easy way and worry about it later?
Of course, if that does happen, it means that you are in a toxic work environment and you need to leave as soon as you can. But it does happen, and I have experienced it firsthand.
Yes doing shit on top of shit will be paid later, but sometimes, maybe that's fine to pay later while you are scrambling to make money in the first place ?
It takes time for well maintained project to detoriate bad end enough for debt to impact business.
Even when it does , both the biz and new tech leaders are likely to refuse to acknowledge debt is important factor or blame it on you or start a rewrite without understanding what is going wrong to build on top of some shiny new tech everyone wants on their resume.
It's also possible to be both meticulous and flexible. Sometimes when I've gotten that "can we worry about it later" question, I'll tell them yes. If we have a big external deadline or something, I'm happy to treat tech debt like a high-interest credit card. We run up the bill in an emergency, and then as soon as the emergency's over, we pay off the credit card.
> You're not going to ask your execs if it's ok for you to take time to eat or brush your teeth.
I like this! I could add: machine shop workers don't ask if it's ok to clean up the mess after a job.
Exactly right, for the most part if the business has enough trust in engineering to do the best they can, the technical strategy to realise business value is up to engineering, including 'debt'.
The most effective strategy I've seen so far is my current employer. We split our time across the quarter. 60% to core product focuses for the quarter, 20% to ad-hoc requests from the business, and 20% to 'tech improvement'. The latter includes personal growth for new engineers related to our stack or exploring new tech, improving our current tooling, and addressing areas of 'tech debt'. This split is agreed with the business, and the tech lead in a team is responsible for maintaining the balance and has autonomy here too - often we see areas of debt that impact our product focuses so that becomes core for example. It takes trust on all sides but seems to be working well.
It wasn't squeezed in only when there was room in the sprint, it may not have even been a formal part of the sprint to begin with.
The PM wasn't trying to fill up the entire sprint with everything they could fit that they wanted to deliver. That's not always the case.
> I think it's a mistake to ask non-experts to prioritize things they don't understand.
It is, but many PMs behave where they have to know what everyone is working on each day (standups) and it has to be what their priorities are as well (via the tickets in the sprint which they plan). This PM you worked with was more open. That's wonderful
Will product managers want to do more than is professionally responsible or even possible? Sure. It's their job to want things. Will some people try to get up in your business inappropriately? Also yes. But the answer to that is to set clear boundaries. Product people make product decisions. Technical people make technical decisions. And technical people need to be ready to answer in business terms why particular choices are optimal for the business. As well as being able to self-run the technical team so that others don't feel obliged to step into a power vacuum.
I think the analogy can work in software development.
Probably works for software development too.
> Carving out time to pay down tech debt requires buy-in from leadership.
Not in my experience! I think one can do pretty well a) refusing to put debt in to begin with, and b) for any new work, including necessary cleanup of what you'll be touching in the estimates.
Some years back I had an explicit understanding with a product manager: the engineers would track tech debt and take care of it in small slices over time. He could always ask for details, but absent his curiosity, we'd just leave him out of it, doing a little bit every week so that things always stayed in good enough shape that we would keep our velocity high and our surprises low. Early on he asked a couple of times, but he quickly realized that to him it was entirely boring.
I think it's a mistake to ask non-experts to prioritize things they don't understand. You're not going to ask your execs if it's ok for you to take time to eat or brush your teeth. You equally shouldn't ask them if it's ok to be a responsible professional and do things like writing tests and keeping the code base reasonably clean. That should just be part of the deal; any exceptions should be temporary and carefully negotiated.