I've worked with a great many 'theorists' coders and they never get anything done. They spend too much time abstracting into nothingness. You know.. the kind of guys who remind you of your 3rd grade grammar teacher making sure you know when to use 'whom' vs 'who'...
While I think eventually one would refine their product so that it uses best practices I would say that having customers and a product should definitely be a prerequisite.
If you do that, you'll run a very considerable risk of wonder why version 2.0 of your product is taking so damn long to ship. The answer: all of the things you punted, ignored, assumed, patched over, and otherwise haphazardly threw together in version 1.0. Now all these have set your code in concrete, and you have to remove half the foundation to get them back out.
It is often that way anyway regardless of planning. You get into it then your needs change over time. By version 2.0 a new foundation will last longer and incorporate things people have learned from the first version.
No, sorry it isn't. Fred Brookes goes into detail when he coins the term "Second System Effect", and it definitely doesn't refer to half-arsed, half-debugged, haphazardly thrown together anything from version 1.0.
The Second System Effect is specifically about new features.
But don't you have to add/remove/edit your comprehensive unit tests after you refactor? Refactoring would have have to include this work needed to keep your unit tests comprehensive.
I've worked with a great many 'theorists' coders and they never get anything done. They spend too much time abstracting into nothingness. You know.. the kind of guys who remind you of your 3rd grade grammar teacher making sure you know when to use 'whom' vs 'who'...
While I think eventually one would refine their product so that it uses best practices I would say that having customers and a product should definitely be a prerequisite.