It's their codebase, they paid for it. If they don't want to maintain it properly, then it's on them. It will just get more and more expensive to maintain until they replace it with newer technology.
Developers fetishize their codebases and complain about unpaid technical debt, but not all the bad code I've run across I can push off to management making the wrong decisions. I've seen a lot of bad decisions made by the original developer too, who just did things improperly.
Devs have this nasty tendency to push their mistakes onto their employer by calling it technical debt. If you're incurring technical debt, then you need to spend some time analyzing it and coming to a real understanding of the tradeoffs you're making in doing it a certain way. Hopefully you'll have documentation somewhere that describes the debt, what's being worked around, and what it would take to do it right.
If you're not doing that, then you're just leaving a mess for the next guy. Messy work isn't technical debt, it's just sloppy work.
> Devs have this nasty tendency to push their mistakes onto their employer by calling it technical debt.
You can't have it both ways. Either the employer owns the code and is responsible for monitoring and managing technical debt, or it's the dev's responsibility and the employer needs to make that clear and hire people who can balance decisions effectively.
Sure you can. They paid for the codebase, it's theirs. You don't own it, whether you have the responsibility for keeping it maintained or not. That's true no matter which approach the company takes to managing their technical infrastructure. They can make decisions about it with or without your input and there's absolutely nothing wrong with that. It's theirs, not yours.
What you own is a responsibility to that codebase and to that company. A responsibility that the company is paying you for. It's your responsibility to not fuck up that codebase. If there are conflicts, you need to bring them up to your employer and let them make the decision.
What I think you're not getting is that tasks like cleaning up, refactoring, etc. are part of the job and that you're not doing your job properly if you don't do them. You do not bring these up to your employer or allow him to stop you from doing them, because they're part of the job.
If you work in construction, clean up is part of the job, you don't ask your boss whether you clean up or not, you clean up and he pays you for the time. Same with dev work. It's not up to them, you are a professional and nobody should tell you how to work. If they don't like it they can fire you, and you can go somewhere that appreciates your professionalism. You'll probably get paid more too.
> You do not bring these up to your employer or allow him to stop you from doing them, because they're part of the job.
I agree with that. Don't need to discuss how sausage is made. OP was pointing out that there are circumstances where the sausage making is micromanaged, which puts a kink in this plan.
Wouldn't put a kink in mine. I'd just carry on as usual. When I write code, I don't release it until it's been cleaned and refactored to my satisfaction. If a micromanaging boss wants to know my progress, the answer is simple. It's not done. He wants to know why, I'll tell him. I'm not happy with X class and I'm cleaning up the methods and reorganizing it. Should only take another hour.
If he starts getting 1984 on me and demanding I cut it short and deploy, then it's time for a closed-door meeting. He might be my boss, but he's not telling me how to do my job.
I agree with many of the points you make, I don't agree with your assignment of blame. Good developers can make bad decisions. It's just that it may not be seen for a year or two. In a SaaS platform it's hard to see around a corner a year from now.
The thing about technical debt, is that once you have accrued it, it doesn't really matter how it got there. You either accept it exists and carry the balance or fix it. And typically, it's the role of management to recognize this.
Developers fetishize their codebases and complain about unpaid technical debt, but not all the bad code I've run across I can push off to management making the wrong decisions. I've seen a lot of bad decisions made by the original developer too, who just did things improperly.
Devs have this nasty tendency to push their mistakes onto their employer by calling it technical debt. If you're incurring technical debt, then you need to spend some time analyzing it and coming to a real understanding of the tradeoffs you're making in doing it a certain way. Hopefully you'll have documentation somewhere that describes the debt, what's being worked around, and what it would take to do it right.
If you're not doing that, then you're just leaving a mess for the next guy. Messy work isn't technical debt, it's just sloppy work.