I reserve the right to change my mind as I grow as a developer and, more importantly, run across situations that reveal to me the true necessities of patterns that I may criticize.

There is no better motivator to write better code than having to dig through another's code.  Here are a few little things I have noticed that I think can improve a code base by simply not doing it.

1. Interface for every class, used by..... one class.

Just because they exist doesn't mean they were intended for every class. I'm tracking down some trivial data access code and I end up having to find the implementation of an interface of a repository. And it's not just that all the repositories all implement a useful 'IRepository' that could have some helpful definitions, its that there is an interface for every repository. Each interface is currently, and will forever only be used by one class. I don't see the benefit at all.

2. Class Library = 1 Tier of N-tier architecture.

Just because we right click and start a new class library project in our visual studio solution doesn't mean that we have now decoupled all of our layers and successfully implemented N-tier architecture.  It can be a warm feeling to opening up a solution and see  Company.Dal, Company,Logic, Company.UI but it doesn't mean there aren't dependency nightmares like building UI controls in the logic layer, or passing HTTPContext into the logic layer.  I agree with Danny Simmons that over complication as an anti-pattern. http://msdn.microsoft.com/en-us/magazine/dd882522.aspx . It is easy for me to visualize what code needs to be written but I always take another moment to consider WHERE it should be written.  I think we need to prove the need to de-couple or just accept the fact that many of our business applications could fit into a UI layer and a Core layer and that's it.

3. In-dependancy Injection for Models in MVC

Dependency injection can be a great tool, like newing up the needed repositories (data access classes) at the top of a controller (MVC Web) or inside the constructor for use anytime anywhere in that controller class. In MVC when you use strongly typed models for your view the model binder will try to instantiate the model on a post with an empty constructor. If you used dependency injection OR were relying on a property to be set for use by other methods in the model object, then you broke one of the coolest features of MS MVC. As far as I can tell, the Controller is the only place you have all the request information and route information to do the work of building and populating view models. I'm not a fan of objects populating there own properties by injecting the data access classes but I love get only properties that are sums of other properties within a class.