Bill Atkinson, author of the original MacPaint, once said: "It’s an art form, like any other art form… I would spend time rewriting whole sections of code to make them more cleanly organized, more clear. I’m a firm believer that the best way to prevent bugs is to make it so that you can read through the code and understand exactly what it’s doing… And maybe that was a little bit counter to what I ran into when I first came to Apple… If you want to get it smooth, you’ve got to rewrite it from scratch at least five times."<p>I am a firm believer in this philosophy and in my own projects, I have had to write several modules several times over in an attempt to make a cleaner interface with changing requirements and features. However, more often than not, imposed deadlines can make this approach daunting. At what point does one decide to stop "hacking" on top of existing code and decide to start over from scratch with a re-write that is presumably more flexible, robust, and easier to maintain. I presume a lot of this has to do with how long I envision the code will remain pertinent. How does one gauge such a metric? More practically, how can one justify to project managers that starting over is a good strategy?