I guess everyone is entitled to their preferences, as long as they don't try to force them into anothers. The problem with the "code a lot, then refactor" appr

I guess everyone is entitled to their preferences, as long as they don't try to force them into anothers. The problem with the "code a lot, then refactor" approach is that it takes a lot of different skills to actually pull off. Some of the pitfalls I have seen are: 1. You need an unusual amount of perseverance, or the feedback of very knowledgeable, outspoken and candid coworkers to actually perform an acceptable refactor, instead of the usual brushing of dirt under a thin (leaky) abstraction. Some of my best work I have done while challenged by colleagues that did not allow me to get away with the "good enough" version I initially wanted to settle with. 2. You need to command an amount of social capital that is not normally granted to mere programmers in order to let the higher-ups that: "Yes, it seems to be working, but no, it is not production ready yet. Do I need to remind you, again, that you agreed to create a throw-away prototype from the very beginning?" In my experience, experimental code - no matter how rough - gets promoted to officialdom status the very minute it's pushed into your source control system. 3. Even if you can navigate #1 and #2 successfully, you still need a lot of forethought in order to design a robust API that will allow your coworkers to interact with your module without being disrupted by your ongoing refactoring. 3.1 As a corollary to the previous one, the effort to communicate the robust API from #3 grows super-lineraly to the size of your team. Not only the probability of someone being left out of the loop grows with N, but also the probability of some idiot^H^H^H^H^H misguided person deciding to ignore all warnings and rely on some implementation detail to accomplish some short term milestone. 4. Finally, you need to actually catch the bugs in order to justify all of the above. This is not an actual skill that need to have in order to do that, but it means that any problem that you might have gets amplified by any defect or omission you may have in your testing strategy.