I am done using the repository pattern in 90% of my projects.

Recently I've found myself starting a bunch of smaller websites for family members and friends. When I start these projects I dive head-first into a solid pattern of development that will extend long-term maintainability and make my code reusable. I pay strict attention to separation of concerns and I adhere to a lot of patterns that ensure proper compartmentalization is done. I then move on and use TDD (test-driven development) to start coding every aspect of the project's domain. I finally top it off by building out the user interface and then a month later I call it complete.

The way I program is the proper way to build an application and have it be around and easily maintainable for a long time. However, I'm changing my tune a little depending on the project. Most of the projects I do are side projects for people who just want a simple solution quickly. My strict adherence to these standards drags out my development time for up to several weeks longer than it would have otherwise. I recently decided to build a project and just go for the quick results. I found that I was able to construct the application in less than half the time that it normally takes me.

I have come to the realization that not all projects deserve a separate domain project in my solution filled with repositories. The project really does need to be weighed from a high level before I make the decision to invest the extra effort in documentation, unit testing, and separation of concerns. I know that in five years if I want to rip out the Entity Framework back-end from one of my smaller projects it will be more work than if I had built a proper seam using the repository pattern and kept the domain free from the burden of data storage. The truth is though, I very rarely revisit any of these smaller projects like that. And in the cases where I do want to revisit an application like that it's very likely that I'll want to do a complete rewrite of the application anyway using the technology of that time.

I guess I have just become slightly more realistic when it comes to very small applications that really only have a one-time use. The ability to adhere to proper design patterns and SoC is a must-have but learning when is the proper time to exercise that ability is rapidly becoming a crucial skill for me.