hacking: 0 < version <= 1.0
engineering: version > 1.0
In other words, as soon as the product is "established" as a pile of hacks, all hackers should be taken off the project (temporarily) and a complete white-room rewrite should be done by a team of engineers, with one of the criteria being "to closely match the original product as possible while creating room for future expansion."
Then, the hackers (now known as "R&D") can have at the new codebase, but in a distributed SCM way--a hacker can only work on their branch, and any approved branch must be white-room redeveloped by an engineer before being put into the clean code-base.
...or, "What I Would Do If I Ran Some Sort of Military Project With Unlimited Funding and No Time Constraints"
"a complete white-room rewrite should be done by a team of engineers"
NO! NO! NO!
Never allow your engineers or anyone else to do a full rewrite of anything that currently works and serves the needs of your users. While they're busy rewriting (and it will take SOME TIME) you're not pushing out new features and your competitors are (remember Lotus 1-2-3?). And if you are pushing new features while your engineers are doing a rewrite they will NEVER catch up.
The solution: Make sure your application has tests from the start (and don't allow any excuses for not writing tests) and you can slowly refactor and rewrite small parts of your app, one bit at a time.
There are some exceptions to this, some companies have managed to successfully rewrite their software from scratch. But consider that a statistical anomaly and don't try to replicate it (and chances are it was rewritten by a team of super hackers, not a bunch of engineers trying to find the most perfect, scalable solution).