I agree that it is good for people to learn to use and maintain wheels instead of building them. I also agree that the experience of maintaining code teaches you a lot about how (not) to write maintainable code. However there are at least three good reasons I would cite for when it is important to rewrite code:
- You need something available in the language you are working in, and the original code is not. The example I cited above was rewriting code in Perl that had been in Expect scripts. Without the rewrite you cannot add consistent error handling nearly as easily.
- The component has been identified as exceptionally buggy. This is based on research at IBM where they found that they could get impressive improvements in code quality by tracking bug count, and then rewriting from scratch the worst 10% of components. The point being that the components usually had some fundamental design flaw, and your demonstrated odds of writing a better component were very good.
- You have completely reconceptualized how the component should work, believe that the benefits will be very large, and accept the costs of an attempt. This is the most dangerous reason, it is easy to fool yourself. However sometimes dramatic change in how something fundamentally works is easiest achieved through a rewrite. (Perl 5 as opposed to Perl 4.) Even so, I think this is an absolute no go unless you make it a priority to support the old model from within the new. The new model needs to not only be better than the old, it needs to subsume it.
But note that while I think there are cases where rewrites are justified, I freely and absolutely agree that people tend to launch into rewrites without sufficient justification...