Where a new system concept or new technology is used, one has to build a system to throw away, for even the best planning is not so omniscient as to get it right the first time. Hence plan to throw one away; you will, anyhow.
— Fred Brooks, The Mythical Man-Month [Emphasis mine]
Build one to throw away. That’s what they told me. Then they told me that we’re all agile now, so we should Refactor Mercilessly. What gives?
Is it always better to refactor my way out of trouble? If not, can anyone suggest a rule-of-thumb to help me decide when to stick with it, and when to give up and start over?
If you’re doing test-driven development, you can refactor your way out of almost any trouble. I’ve changed major design decisions without much trouble, and rescued decade-old codebases.
The only exception is when you’ve discovered that your architecture is completely wrong from beginning to end. For example, if you wrote your app using threads, but you discovered that you wanted a bunch of asynchronous state machines. At that point, go ahead and throw away the first draft.