Re: Appropriate amount of abstraction

[etcshadow]

It's a ridiculous oversimplification, but a good rule of thumb is: whatever level of abstraction you could be working at, to get the job done, you will be much more successful if you actually work (or at the very least understand and maybe fiddle around a little) one level of abstraction lower. You won't just write more efficient code that way, you'll have a better understanding of the landscape that your particular layer of abstraction exists in.

For example, if your job is to build business logic at an object layer, over an object relational mapping abstraction (like Class::DBI, for example), then you're going to be able to do a significantly better job by going one level deeper, that is: understanding and possibly working with SQL. If you try to do some really hardcore business logic at the object-relational mapping layer without understanding the relational layer, you will basically write crappy code. It will be slow and it will do ugly things.

Likewise, if you are trying to write a web application server, then you should really understand at the HTTP layer what is going on. Don't just rely on the fact that apache (or whatever your HTTP tool of choice is) will do it for you. Read the raw socket traffic, look at the headers, that sort of thing.

Obviously, the better the layer of abstraction, the less meat this argument carries. For example, TCP is a good enough layer of abstraction, that I wouldn't tell you to fiddle around really deeply in the TCP stack if you wanted to write some new layer 5 protocol. That kind of extremely well built layer of abstraction, however, is more the exception than the rule.

I think that Paul Graham (or maybe it was Joel Spolski) wrote something about this... But his point was more along the lines of: along whatever axis you want to differentiate your product, punch one layer of abstraction lower than you would otherwise have to... I think his specific example was that if you are writing a graphically driven game, don't use the available 3D graphics packages: write your own instead. That sort of thing... but it's still a similar point.