This seems like a great idea if you are committed to immediately refactoring. The problem is that most people move onto something else as soon as they have some

This seems like a great idea if you are committed to immediately refactoring. The problem is that most people move onto something else as soon as they have something that works. In this case, the code becomes a maintenance nightmare until someone actually takes the time to refactor it. 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.