I think the perspective I was taking in my post was that many bosses do not fully understand the inner-workings of the codebase for their own product and they also don't need to maintain it. So developers truly are the best person to help weigh the need for maintenance.
Of course, there are bosses that fully understand all of this and if you're lucky enough to work for one - awesome.
The other point here is that the new code is new code.
The old code may have been old, but maybe it has been running for a long time without problems. Maybe some of the ugliness of the old code has to do with handling bugs and corner cases that the programmer has forgotten about.
The boss may not have to maintain the codebase and maintain the code, but he/she may have to take the heat for things when someone goes and breaks code that was ALREADY WORKING with their rewrite.
"Why did you let this idiot break our product?" will be the question that the boss will be asked, in this question, and when they say "Well, I didn't know that he was making changes for no reason" someone is on an express path to getting fired.
Fundamentally it is a deeper problem. If you have to put your hand up in order to be allowed to go to the loo, you are not in an environment that respects human dignity.
If you have to ask permission in order to do the right thing then you are in an environment that is ethically deficient. Moreover, despite everybody claiming to value success, it is likely that your definition of success is significantly different from the PMs definition of success.
Their definition of success is likely to be something like "all activities marked as completed and on time", whereas your definition of success is likely to be something like "the bloody thing actually works properly".
This is why testers have such a sucky job, because they always come under pressure from the PMs to give the final sign off on something that they know isn't working properly or 'good enough'. Testers that do their job properly and stand up to the PMs are in danger of losing their jobs. This is why testers need an 'advocate' that has at least as much political clout as the PMs (if not more so - if the PM is putting pressure on the testers to sign off on a crappy product, it isn't the testers who should get sacked...)
When I—a development manager who still works with the codebase—tell my guys that I don't want them working on that particular piece of code it's precisely because a) I know things about the overall design and project that they don't, and b) I know what needs to be done next.
Yes, I want my employees asking whether they should be spending the extra time to make something subjectively better. Once the code works, we need to weigh the time it will take to clean the code up vs the time to do the next task.
Code cleanup should NEVER be a sole task, and it should probably not be a solo task if it is (and if it is, it had better be one of your two or three best programmers in the company doing it). I have told folks not to make changes NOW, because we are revisiting the code in two sprints for the next major milestone. Meeting the current milestone is more important than aesthetics, and it isn't an ethical deficiency at all.
(Hopefully this is sensible; composed on the iPad right before bed.)
Let me be clear - I think that before programmers start throwing off their shackles and asserting their 'rights' they need to build up trust with the PMs.
I do this by consistently delivering high quality code on time and reporting back to them about progress. I assure them that I'm not going to drop them in the crapper by trying to conceal a problem until it is too late, I am very up front and honest about any problems and try to give them plenty of advance warning.
In return, I expect to build trust and the coinage of the realm is autonomy. They show me the plan, and I figure out the best way to get us across the line relatively unscathed.
I think the perspective I was taking in my post was that many bosses do not fully understand the inner-workings of the codebase for their own product and they also don't need to maintain it.
Worse yet are the bosses that used to be a part of the programmers, but moved on a long time ago. They tend to fight for preserving the existing architecture of the application, even when it is clearly inadequate for the task at hand. To them, preserving their illusory understanding of the codebase is more important than allowing the application to evolve.
Of course, there are bosses that fully understand all of this and if you're lucky enough to work for one - awesome.