I was recently engaged in discussions about the use of design patterns that resulted in my reflecting on projects I've seen where I judge design patterns to have been used successfully. Design patterns can indeed add significant value to a solution and its long term viability and success. They can also add a great deal of complexity based upon the pattern in question. The more main stream the more likely the code will pass the maintenance test where another developer can pick up the code and successfully make modifications or additions that properly adhere to the pattern in play. The more obscure the pattern the less likely another developer can easily maintain.
As I reflected on times where I've seen patterns be successful I kept coming back to a commonality of what I refer to as a guidance solution or guidance framework being in place early on. This boils down to work being done up front to put in place a detailed example of how code will be written. It involves items such as creating a solution, putting stubs for various code projects that will hold the UI, data layer, business logic, etc, Enterprise Library or other core components included, and then building out some portion of the solution that hits the database or performs some other item of functionality that will be fairly common within the code base. An ASP.NET web project example would be getting the solution setup, establishing multiple projects to hold different tiers of code, getting the authorization provider up and going, and building a secured maintenance page that retrieves and allows updates of data from a data source. Plugging in the use of data retrieval, error handling, audit trail, and logging, and demonstrated use of design patterns such as MVC, MVP, factory, etc to provide a concrete example. This stubbed out solution then serves as a working example for other developers to emulate in writing their code so they aren't starting from scratch themselves.
Guidance Solutions / Frameworks certainly don't guarantee success by any means, but the times I've seen them in play from the start other developers have been able to roll on to the project and contribute fairly rapidly without an extreme learning curve. The key being that it needs to be done up front to maximize the value and serve as an example for consistency from the start. Otherwise there is an inevitable part of the project where refactoring is forced to take place to bring consistency to a code base riddled with inconsistency as many of the developers chose different approaches to common items such as database access, logging, and exception handling. Having the guidance framework in place from the start helps avoid this what can be time consuming and costly quality issue phase on projects. Even better is if the up front work is done with more common practices that are well known and will require less education within the team and a higher chance it will be willingly adopted over having to force adoption.
