I just finished an app with 51 separate modules, every one hard coded in infinite detail, and much of the code duplicated, 4000 LOC in all. Crazy, right? I used to think so, too. I could have written one very flexible parameter driven module in a few hundred LOC.
But guess what? Even though I bitched and moaned the whole time I wrote the monster, I was able to refactor and "genericize" it in one day. Start to finish time was much shorter than if I had written the flexible module first (that is, if I had ever finished).
This was a non-intuitive lesson for me. Write the specific case and extend later. I always used to try to write the most comprehensive "able to do anything" code until I realized that sometimes, the long way around is actually quicker.
Thanks again Jason, for #3.
When immediate refactoring is unlikely (either due to laziness, lack of focus, or feature deadlines), some kind of balance has to be reached on what should be more general and reusable and what should be hard-coded and specific. And then we're right back where we started.
But reading and thinking about your posts has been very insightful. On my next project, I will try your approach. I agree that in the long run, it is likely to be a more efficient use of time. I imagine, though, that someone coding in this style will either have to have a great memory or take good notes in order to know where similar code is located. Especially consider the case of generalizing the code from one project to another project.
Here's the good news: I couldn't wait to refactor. I was "in the zone" the whole day. And it felt great. I finally got to clean up the mess that I made, and best of all, I didn't have to struggle trying to figure out how to handle that strange outlying case: it was all already there!
I don't know if I'd try this in someone else's shop. You're right; they'd probably pull me off before I got to refactor, leaving a mess for someone else with nothing learned.