A few days ago I read this post, in wich Jeff Atwood writes about abstractions, and how they all "leak" in one way or another. This is true, as a abstraction solves the generic problem, not our specific one. One thing we seem to forgett, however, is that all code we write is acctually a abstraction. There is no way for a computer to understand a c# if statement. It has to be converted to machine code before the computer can execute the comand. There is alot of different abstractions, some good and some not quite as good. But they are all there for a reason.

Jeff had Linq-to-Sql as a example of a abstraction and showed that the sql query could be written in a better way. But so could the machine code that is acctually executing. The lower you go, the more you can optimize what your doing. But who would spend hour after hour writing code that solves a very small problem? The reason we use abstractions is to save development time. At a very low level you can optimize every part of a application, but in the end, it´s just not worth the time it took to develop the application. We should not be scared of new abstractions because then we will never move forward. Would you argue against me if I saied that I would use the .NET framework for my next web application?

Another good thing with abstractions like a ORM for example, is that they will give you alot more compilation error and alot less runtime errors. And everyone who has spent time debugging a application, knows that this is worth alot of time and patience. Even if you loose a few milliseconds in response time, alot of the time it is worth the time you earn not having to fix bugg after bugg after the application is released to production.

There is, of course, times when you should avoid specific abstractions. But as I wrote in my last post, I think we spend to much time optimizing the wrong thing. It´s better to find the real bottle neck and fix that issue first. When you think about using a tool, don´t just think about what you will loose in response time (this is of course important as well), but think about how much development time and maintenance time you will save as well. You will loose users if you have a slow web page, but the same will happen if the user sees a error page to many times. No developer writes perfect code, but the sooner we find our errors, the better.