Taking a perusal of Anders Hejlsberg's
intriguing work on Language Integrated Query (LINQ) constructs for .NET has been an interesting tour of that troublesome problem we encounter all too often in modern software development: abstraction impedance. Especially since the newer development projects I've seen deliberately acquire a large mass of libraries, frameworks, standards, and products to begin their work with, I've only seen the problem of abstraction impedance grow instead of recede.
In any case, Barry Gervin's blog in particular has a great list of LINQ resources, the first one which is the project overview document. I took a close read of this last night, and as I try to throw myself back into the service description language comparison again, I find it some excellent food for thought on this subject.
Figure 1: One possible way to visualize abstraction impedance between objects and other abstractions
The premise of the LINQ project, and many others like it, is the following: Now that the object-oriented paradigm has become established as the predominate model of abstraction in software development, developers have been incurring a large amount of overhead in mapping it to other abstractions, specifically XML and relational databases. I personally make this observation almost on a daily basis in my work as XML, databases, and other models become critical elements of the systems I'm involved in. The drive towards POJOs, the widespread use of Hibernate, and the growing use of persistence annotations are all attempts to deal with this problem. And the developers I work with spend way, way too much time mapping one abstraction model to the other. As I've written about before and as some respected industry commentators have observed, the burgeoning service-oriented view of enterprise architecture, with web services using XML, is fundamentally at odds with the OO paradigm.
How much time does a developer spend overcoming abstraction impedance? That's a good question. Finding hard numbers is difficult, even to bound the problem, but as software development becomes increasingly commodotized, uniform, and cost managed, removing productivity obstacles in the double-digit percentages will be a hot topic. I was able to find a recent citation by Oracle that up to 40 percent of a developer's time is spent dealing with this, which is the usual industry estimate I believe. If true, that's a pretty non-trivial number but it seems about right from what I've seen.
But this doesn't capture the full nuance of the problem. Abstraction impedance isn't just a developer productivity tax. It leads to subtle and pernicious defects in software, contortions of design, and severely degraded performance. All of these lead to low quality software that doesn't deliver the expected value to the customer. The diagram in Figure 1 shows the two major types of impedance (structural and behavioral) along with the different abstraction mappings that objects typically have to deal with including XML, HTML, IIOP, relational tables, SQL, and XPath/XQuery. Certainly there are other mappings, many others, but this captures the major ones. One important axis is conversion cost, which denotes the full cost, both in developer time and run-time. Note that I believe binary formats tend to have the lowest impedence and lowest conversion cost and I reflect this in the diagram. This isn't necessarily good news for XML, but fortunately there are also many smart people trying to solve XML's unique impedance mapping at the present, so I do expect the issue to improve.
So, I find the LINQ effort to be admirable and extremely interesting and I'm eager to see how effective it is. Solving this problem well may end up being one of the bigger advances in software development this decade.
Technorati: Enterprise Architecture, Computers and Internet, Programming, XML