Rule #1 for building software. Simplicity.

Most good discussions wind up quoting someone famous, so here’s mine to get us started:

"Everything should be made as simple as possible, but not simpler."
-Albert Einstein

As geeks, we are drawn to adding layers of abstraction. Maybe it’s because it makes us feel smart. Maybe it makes us feel clever. Maybe we think we are better developers because we are engineering for the future. Maybe we are trying to impress our colleagues by showing that we "follow best practices".

Why do we add layers of abstraction? Well, we tell ourselves it’s to make future changes easier. That makes sense. But too often, the scenario for the abstraction layer becoming worthwhile is contrived beyond practical reality. When that happens, you have become cargo cult programmer.

So we add a layer of abstraction to our code under the guise of making it more extensible, usually without fully considering the key consequence of layers of abstraction: increased complexity. More layers to dig through to find problems. More code to maintain. More code to document. More code for the new guy to understand before he can be productive.

Beyond the human implications of having more complexity, don’t forget it’s harder on our servers too, because those extra layers of code also take more CPU cycles to calculate.

My suggestion? When you add a layer of abstraction, make sure that it’s needed in the foreseeable future, and the scenario for it’s use is very likely and thought through, otherwise, skip it and keep things simple.