16 Jun 2012. comments
Today I went back and re-read Joel Spolsky’s advice ‘The Law of Leaky Abstractions’:
“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 has 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 are obviously important but each time you create a new one you should ask yourself a series of questions:
- Does this abstraction make your code easier to write?
- Does this abstraction make your code easier to understand?
- Does this abstraction make your code easier to troubleshoot?
- Are you better off with it than without?