The Law of Abominable Abstractions

Twitter is one of those things that I just don't get. It holds no appeal for me. But plenty of other people apparently can't get enough of it–to the point where the Twitter site gets around 11,000 page-views every second. That's an impressive amount of traffic.

Twitter’s Woes
It’s therefore not surprising that there’s been a bit of a buzz among Web developers in the blogosphere stemming from some of Twitter’s reported growing pains. But the buzz really isn’t about Twitter, it’s about problems with the development platform that it was built on: Ruby, or Ruby on Rails (ROR). Specifically, developers are weighing in on whether or not Ruby can scale or not. This is because Ruby is an interpreted language–meaning that it’s roughly on order of 100 times slower than a page created in, say, ASP.NET written in VB.NET or C#.

Development: It’s All About the Abstraction
My point here, however, is not schadenfreude. Because even if I do like ASP.NET more than Rails (and I do), it’s not like ASP.NET is immune from problems either. As we all know: when it comes to development, everything is a trade-off. In the case of Rails, developers trade execution speed for decreased development time–with the mindset that hardware is easier to throw at a problem than development time. In the case of ASP.NET, abstractions help overcome the stateless nature of Web applications and provide developers who are unaccustomed to the HTTP client-server model with webforms that shield them from the underlying complexity. But there’s a trade-off, because developers using ASP.NET aren’t able to gain full control of their emitted markup/HTML (without a hideous amount of effort). This is something that’s driven me batty on a number of occasions because I’m a big proponent of creating clean separation between markup, behavior, and styling; something that just isn’t possible with ASP.NET as it stands today. (But happily the ASP.NET MVC Framework looks to change all that–and I’ll address those developments in a subsequent article.)

The Law of Abominable Abstractions
In some ways, what I’m talking about here is Joel Spolsky’s Law of Leaky Abstractions. Both of the cases I’ve just mentioned are classic examples of using an abstraction to drastically simplify interactions with complex systems. And both cases are subject to ‘leaks’ that CAN cause developers some serious stress and even anxiety.

But that’s all just background. I want to take things one step beyond Joel’s Law of Leaky Abstractions – to the level of Abominable Abstractions. In other words, Joel’s notion of Leaky Abstractions is spot on: We all understand that creating abstractions is difficult and prone to error. No one in our profession doubts that. But every once in a while, I bump into something that really pushes the limits and just drives me batty; almost to the point where the creators of the abstraction have taken hideous liberties–bordering on the point of abuse.

I’m sure that in their minds, the creators of these abominable abstractions were justified. But to the rest of us, their decisions border on insanity. Worse, however, is the fact that most of these abominable abstractions that I’ve encountered seem to stem from someone’s need to ‘help’ people. Meddle would probably be a better word. Let me give you two examples.

IE7, ClearType, and CSS Opacity–Oh My!!
I first encountered the poster-child for abominable abstractions when a developer buddy of mine wouldn’t shut up about how much grief he was having getting around dynamically setting the opacity of text in Internet Explorer 7. After a bit of searching, it became apparent that others were encountering this bug and weren’t happy with it. At this point, I assumed we were just dealing with a bug, or in this case, a leaky abstraction.

It turns out this wasn’t a bug. Instead, a program manager at Microsoft decided to ‘help’ by actively disabling ClearType in cases where developers were dynamically transforming text. The result is that trying to dynamically render the opacity of text on a Web page becomes an almost Herculean task for IE7–where it’s not that big of an issue with Firefox or IE6. This, in my mind, is an absolute crime–even if the goal was to ensure good readability. And, just so we’re clear, the question here isn’t about ClearType (because I realize that some people HATE it and others LOVE it). The question is whether or not a browser should be able to change your system settings in order to render text. Because even if you hate ClearType and find yourself snickering that IE7 turns it off in this case, you have to agree that you’d feel dirty if you coded something like this into one of your solutions. Which is why, in my mind, it’s an abominable abstraction.

Note: If you use ClearType and want to see this abominable abstraction in action head out to Microsoft’s IE 7 home page, and click the Resources and Solutions link on the right navigation bar. While it may be hard to spot, the text under all of the links that dynamically pop up is bereft of ClearType (compare the same page in Firefox with ClearType enabled). Microsoft has tempered the negative impact of this abominable abstraction on their own site by using a heavily smoothed font, but they have other properties where the effects are much more pronounced.

Permissions Inheritance on Windows Server 2003 with SQL Server
Another example of an abominable abstraction comes from someone, somewhere, deciding that normal inheritance rules for permissions shouldn’t apply to some folders where applications like SQL Server are located. I’ve only bumped into this problem a few times, but each time that I did it forced a double take. For the most part I install SQL Server using a least privilege approach. But sometimes I take a sloppier approach (such as when I’m setting up a temporary test or development server). In those cases I’ll frequently create a domain user and then give them Modify permissions on the entire Microsoft SQL Server folder in the Programs directory. If I did that in other directories, the Modify permission would inherit down to child directories, and so on. But on Windows Server 2003, I could swear that those permissions don’t propagate down to some of the sub-directories when SQL Server 2005 is installed. This means that in order to get my changes to stick, I have to go in and manually check the sub-directories and re-add my permissions changes.

Now I realize that security is a complex issue, and I love dealing with the abstractions of ACLs and Windows Explorer (much nicer than having to wrestle with manually appending security descriptors to all of my files in hex-code). And I understand that hackers might be able to jump from one set of SQL Server resources to another in a poorly configured environment. But someone, somewhere, made the decision to ‘help me’ by purposefully pre-empting one of my explicit decisions. And that doesn’t help me. Instead, it drives me batty, and earns the designation of an abominable abstraction because it’s a clear case of unanticipated behavior completely overstepping its bounds.

Sound Off
What about you? Have you bumped into any abominable abstractions? Feel cranky enough to spout off about them? Or just want to see what others have written about this topic? Come sound off in the new WindowsDevPro Development Theory forum.