I was reminded this week why it's important not to be lazy when it comes to design, specifically when it comes to our refactoring moments ... no matter how insignificant you think it might be at the time.
Early on in my first SharePoint project, I had the tasks of creating 3 lists for a site dynamically (2 document libraries, 1 picture library). When I asked if we'd need to create other types of lists on the fly, I was told "no, these will be the only three." So it was extremely tempting to just create 2 routines (1 for the document libraries, 1 for the picture library) and be done with it. Upon further review, I noticed that I could create one routine for both; question is, was it worth the refactoring effort for only 3 lists?
I choose to refactor, it just didn't seem right to me to have the same identical functionality in two places. You can only guess what happened later ... that's right, the scope of the project changed upon which we needed not only needed another 10 discussion boards - but they also needed to be dynamically generated based on another list already created. Happy that I refactored to one routine, I simply added one more line of code to the existing loop and was finished.
Having said that, a lack of refactoring in this case would not have hurt this project at all (it would have been easy to refactor at that point as well); but in a different scenario that was more complex and further along in the project, I know it would have been much more tempting not to go back and refactor that code. The only way to prevent that is good design, especially at the beginning of your project.