2 ms·

>I don't disagree at all, but I think the more valuable advice would be to explain how this can be done at a typical company. I resolved to try this if I ever

>I don't disagree at all, but I think the more valuable advice would be to explain how this can be done at a typical company. I resolved to try this if I ever ran into the same problem again after a whole bunch of arguments at a previous few companies: * Set up a (paper) slider with 0-100% on it and put it somewhere prominent on the wall. Set it at 70%. That's the % of time you spend on features vs. the % of time you spend on refactoring (what that entails should be the development team's prerogative). * Explain to the PM (or their boss) that they can change it at any time. * Explain that it's ok to have it at 100% for a short while but if they keep it up for too long (e.g. weeks) they are asking for a precipitous decline in quality. * Track all the changes and maintain a running average. I think a lot of people suspect that management would just put it at 100% and leave it but I suspect that wouldn't happen. Most manager's "cover their ass" instincts will kick in given how simple, objective and difficult to bullshit the metric is once it's explicit.

jacquesm 9y ago
That's a good one, I will definitely steal that. Thank you!
DougWebb 9y ago
I'd call it "Maintaining existing code" rather than "Refactoring". To a non-technical manager, the former sounds like pretty much what it is, and won't raise many questions. (If they do question it, ask them if they maintain their car while it's still running ok, or just wait until it breaks down before they do anything to care for it.) Refactoring, on the other hand, sounds like a buzz word, and if they look it up they'll get "rewriting code that's already working so that it continues working the same way". They probably won't get the nuances about why that's a useful thing to do, so it'll sound like busywork and they won't be happy with letting your team do it. They also won't be able to justify it to their management if they're questioned about it, which is critical for getting buy-in from your managers.

jacquesm 9y ago

That's a good one, I will definitely steal that. Thank you!

DougWebb 9y ago

I'd call it "Maintaining existing code" rather than "Refactoring". To a non-technical manager, the former sounds like pretty much what it is, and won't raise many questions. (If they do question it, ask them if they maintain their car while it's still running ok, or just wait until it breaks down before they do anything to care for it.) Refactoring, on the other hand, sounds like a buzz word, and if they look it up they'll get "rewriting code that's already working so that it continues working the same way". They probably won't get the nuances about why that's a useful thing to do, so it'll sound like busywork and they won't be happy with letting your team do it. They also won't be able to justify it to their management if they're questioned about it, which is critical for getting buy-in from your managers.