Ted Neward recently commented about a comment that Scott Hanselman made during the patterns & practices Summit. Scott said that his company Corillian had built an abstraction layer atop of log4net. From Ted's perspective, the Java world has been dealing with too many layers of abstraction for the last decade they are paying the price for it (agreed). Ted also brings up YAGNI, suggesting that layers are added without an existing need.

In my opinion they are both right (way to take sides huh?) Java is attempting to dig itself out of a hole, an example of this are the changes made to EJB 3.0 compared to EJB 2.1, take a look. However there are valid reasons to build abstraction layers, even if it's only a layer onto of logging. What are those reasons and when is it valid is where the gray area comes into play. You see it all depends, but I think you can break it down to the relative concern you have with your application or SDK (in Scott's example) relying on external dependencies. As we introduce dependencies we become slightly more reliant on the versioning and support of said dependency. While taking on dependencies that are open source may mitigate some of this risk as we may have access to the source code, it is something we need to take into account.

We all know that Microsoft likes to change their data access libraries every 5 to 10 years, so if you are building a product that is intended to transcend that margin, an abstraction might just very well be a good choice. If you look internally to Microsoft, as Joel stated, the Excel team uses their own C compiler to mitigate risk and eliminate dependencies. I applaud Scott for the long-term vision of the Corillian product.