The .NET Abstraction Pile

I ran across this really cool article by Eric Sink that does a good job at reminding us not to forget all the abstraction layers that we as software developers tend to rely on, and the tradeoffs we make by using them.

The most important point in this whole article is this:  You need to understand what's going on inside all your abstraction layers.  Each abstraction presents an illusion, but the best decisions happen when you can see through the illusion.

If you have a deep understanding of all the technology abstractions that are involved with your software, then you have two big advantages:

You can quickly isolate problems.

You can develop an intuition which will help you avoid those problems in the first place.

The first point is fairly obvious.  Troubleshooting goes much better when you know what's going on.  Have you ever watched someone try to solve a problem in the presence of several abstractions they didn't understand?  They feel helpless.  Usually, they start making wild guesses about where the problem could be.  I call this "stab in the dark debugging". 

More importantly, if you can see through most abstractions then you can develop an intuition to make much better technology decisions.  Choosing the right libraries and components in your platform can prevent lots of problems before they ever happen.

When I build apps, I do this all the time, by building them in an n-tier approach and building a Test Harness for each tier.  It helps me logically isolate my bugs into the tier that caused them, and in the end produces better (less bugs) code.

Don XML