The concept of leaky abstractions was introduced by Joel Spolsky in his blog 7 years ago, but it's not as widely known as it deserves. So here is the basic definition:
All non-trivial abstractions, to some degree, are leaky
This simply means that if you're trying to hide something beneath your abstraction layer - it will almost always show itself up. These errors are hard to detect and have severe consequences. There are many examples of leaky abstractions:
- Some SQL queries are thousand times slower than their logical equivalents - DB implementation leaks into SQL
- SQL, in its turn, has abstractions over itself like NHibernate or Linq to Sql - and rather often you have to deal with SQL directly losing many abstraction benefits
- When you program GWT and write your code in Java it is later on translated to JavaScript. And what can be more confusing than having a JS error from running your Java code? :)
- .NET is an abstraction over Win32 and it has leaks sometimes - rarely, but these rare cases make people mad
- Any component framework like ASP.NET or JSF hides HTML/CSS and JS beneath them - guess what problems you may have?
What can be a conclusion of all above? It's all in Joel's original post!
Never hire a developer for working with some abstraction if he doesn't know direct underneath layer of it
It may sound strange or may be offensive for some of us but it's rather obvious: you should not hire an ASP.NET developer if he is scared of JavaScript or hire a so-claimed NHibernate guru if he doesn't know what 'DISTINCT' is?
No comments:
Post a Comment