3 ms·

I dunno, after you do the rewrite, then what? If the bureaucrats won't ever let you make incremental fixes/cleanup, then even your rewritten version will eventu

by dack 10y ago

I dunno, after you do the rewrite, then what? If the bureaucrats won't ever let you make incremental fixes/cleanup, then even your rewritten version will eventually rot. I think the idea of building software "the right way, once and for all" is mostly just wishful thinking on our part. Even the ideal rewrite will have ongoing maintenance that needs to be done. Therefore, my only two options in that situation would be to a) make those incremental changes as part of features without telling them (estimated as one chunk), or b) look for a new job.

DougWebb 10y ago
At my old job, we built, maintained, and operated a huge customer-facing system. We had 2-3 big releases per year, and in every release cycle we devoted around 20% of our time to maintenance, whatever time was necessary for critical bugs (generally from the new code released in the last cycle) and the rest to new development. We (the dev team) put this split into our estimates and development plans, and we had official approval from the project management team and c-level execs. That 20% time was ours to use as we saw fit, and we generally used it for refactoring code we felt was hampering productivity on new development. But we also used it for side projects; I built a performance/metrics gathering and reporting system that was incredibly useful to me, and ultimately became incorporated in marketing materials and the ceo's presentations. We were lucky to be able to use this 20% time openly, but if we weren't we would have increased our new dev estimates to get the time.
cubano 10y ago
All b) really does is start the loop over again at the initialization step.
chris_wot 10y ago
Michael Feathers considers legacy code to be any code without tests. [1] I tend to agree - only I think even code with tests can be candidates for the "legacy" moniker. Bottom line is: you may do a rewrite, but that codebase may be considered to be a hairball by the next guy. 1. http://www.netobjectives.com/system/files/WorkingEffectivelyWithLegacyCode.pdf http://www.netobjectives.com/system/files/WorkingEffectively...

by dack 10y ago

DougWebb 10y ago

At my old job, we built, maintained, and operated a huge customer-facing system. We had 2-3 big releases per year, and in every release cycle we devoted around 20% of our time to maintenance, whatever time was necessary for critical bugs (generally from the new code released in the last cycle) and the rest to new development. We (the dev team) put this split into our estimates and development plans, and we had official approval from the project management team and c-level execs. That 20% time was ours to use as we saw fit, and we generally used it for refactoring code we felt was hampering productivity on new development. But we also used it for side projects; I built a performance/metrics gathering and reporting system that was incredibly useful to me, and ultimately became incorporated in marketing materials and the ceo's presentations. We were lucky to be able to use this 20% time openly, but if we weren't we would have increased our new dev estimates to get the time.

cubano 10y ago

All b) really does is start the loop over again at the initialization step.

chris_wot 10y ago

Michael Feathers considers legacy code to be any code without tests. [1] I tend to agree - only I think even code with tests can be candidates for the "legacy" moniker. Bottom line is: you may do a rewrite, but that codebase may be considered to be a hairball by the next guy. 1. http://www.netobjectives.com/system/files/WorkingEffectivelyWithLegacyCode.pdf http://www.netobjectives.com/system/files/WorkingEffectively...