Cleanup is not about how the code works at runtime, but how well it supports change. An abstraction that looked right at the time shows its cracks years later. Changes that should be simple and low-risk become intense and scary when they need to fit in with it.
It's not insulting. For one thing, the person proposing the change may very well be the original author. For another, you have the benefit of hindsight and access to information they didn't about what bugs would emerge, which features would be demanded, and how hard it would be to implement them. Of course you're going to see better ways of doing things than were visible on day 0.
Increasing speed and reducing risk for all future iteration is some of the highest impact work you can do; rather than shipping a single feature, you're a force multiplier for all the features developed by your team.
The only time it makes sense to skip cleanup is when you're content to just let the thing run, and don't see any changes in the pipeline.
It's not insulting. For one thing, the person proposing the change may very well be the original author. For another, you have the benefit of hindsight and access to information they didn't about what bugs would emerge, which features would be demanded, and how hard it would be to implement them. Of course you're going to see better ways of doing things than were visible on day 0.
Increasing speed and reducing risk for all future iteration is some of the highest impact work you can do; rather than shipping a single feature, you're a force multiplier for all the features developed by your team.
The only time it makes sense to skip cleanup is when you're content to just let the thing run, and don't see any changes in the pipeline.
reply