If an engineer gets bored and leaves because they wanted to rewrite your codebase and you said no, that's probably not an engineer you wanted to retain anyway.

If an engineer gets bored and leaves because they wanted to rewrite your codebase and you said no, that's probably not an engineer you wanted to retain anyway. Even if you said yes, you're only kicking the problem down the field a bit, because six months later they'll get just get bored of the new stuff they've rewritten and will want to move on to rewriting something else. Ad infinitum. I consider these people the "90% engineers", meaning they like to take a project from 0% to 90% complete, but then once the going gets tough, and they're no longer writing new code but trying to track down the bugs in their existing code, they decide it's no longer fun and need to move on to something else. These people usually fail to realize the implicit risks associated with throwing away an existing codebase and starting over from scratch. All that time spent ensuring the business logic is correct and tracking down obscure bugs will need to be repeated in their new rewrite. (Spolsky elaborates: http://www.joelonsoftware.com/articles/fog0000000069.html http://www.joelonsoftware.com/articles/fog0000000069.html) These people are essentially spinning their (or rather, their company's) wheels by creating more work for themselves, without actually getting anything done.