Today I went back and re-read Joel Spolsky’s advice ’The Law of Leaky Abstractions‘ . It hits the nail on the head:
“Learn how to do it manually first, then use abstractions to save time. Code generation tools which pretend to abstract out something, like all abstractions, leak, and the only way to deal with the leaks competently is to learn about how the abstractions work and what they are abstracting. So the abstractions save us time working, but they don’t save us time learning. And all this means that paradoxically, even as we have higher and higher level programming tools with better and better abstractions, becoming a proficient programmer is getting harder and harder.”
And here’s what Jeff Atwood famously said about leaky abstractions in his blog post ’All Abstractions Are Failed Abstractions’:
“We programmers keep piling up these leaky abstractions, shoring up as best we can, desperately attempting to stay ahead of the endlessly rising waters of complexity.”
Abstractions can be valuable, but you should ask yourself a series of questions:
1. Does this abstraction make your code easier to write?
2. Does this abstraction make your code easier to understand?
3. Does this abstraction make your code easier to troubleshoot?
4. Are you better off with it than without?comments powered by Disqus
(c) 2013 Ben Lakey
The words here do not reflect those of my employer.