--- title: Why industry analysts, more than most, should beware leaky abstractions date: 2006-05-12T20:43:47Z modified: 2006-05-12T20:43:47Z permalink: "https://redmonk.com/jgovernor/why-industry-analysts-more-than-most-should-beware-leaky-abstractions/" type: post status: publish excerpt: "" wpid: 598 categories: - Uncategorized timestamp: 2006-05-12T20:43:47Z tags: - Uncategorized --- Proud new dad [Bill de hO’ra](http://www.dehora.net/journal/) was [talking about programming languages on his blog](http://www.dehora.net/journal/2006/05/vurt.html) and it got me to thinking about what worried me when I read that [Burton Group](http://www.burtongroup.com/)‘s [Anne Thomas Manes](http://atmanes.blogspot.com/2006/05/unrest-over-ws-and-other-enterprisey_09.html) is proud of mixing the enterprisey coolaid we know as [WS-\*](http://www.loudthinking.com/arc/000585.html). > People accuse WS-\* of being too complex. (Somewhat remarkable when you think back to 2000 when everyone was extolling SOAP’s simplicity.) Well — if, as a developer, you need to understand the details of all 60+ WS-\* specs, then, yes, WS-\* is way too complex. But that’s a symptom of WS-\*’s immaturity. If we had proper tooling, the only folks that would need to be concerned with all the 60+ specifications are the folks implementing the WS-\* toolkits. Developers should really only need to be concerned with a handful of the specs: SOAP, WSDL, and XML Schema–maybe WS-MetadataExchange. Everything else should be handled _**transparently**_ by the toolkits. I think we’ll get there. Microsoft’s WCF ("Indigo") demonstrates how easy it can be to use WS-Addressing, WS-ReliableMessaging, WS-Security, WS-Trust, and WS-SecureConversation. All you have to do is specify an annotation, and everything is automatically implemented behind the scenes. I expect the other vendors to deliver better tooling at some point. Now that WS-Policy has finally moved into the [standards track](http://www.w3.org/Submission/2006/06/), we should start getting much better configuration tools. \[italics mine\] I know too many great developers, people like Bill, who shudder at these kinds of sentiment – "everything else should be handled" transparently… or opaquely? Cote, say, is an industry analyst now, but was an ISV developer just a few months ago. His teeth start hurting when people talk about auto-generating code and "hiding complexity". As I see it, is that you probably really need to understand something of both the abstraction and the internals to really get things done. Otherwise you end up handing off potential problems to people that actually do know what they are doing when they have to debug your code. I have seen too many JEE apps that performed like dogs because the developer didn’t understand how databases work, to believe that abstraction solves IT problems. Smoothsurface this, and the complexity will almost certainly pop out elsewhere. A jumbo jet looks pretty straightforward, but I wouldn’t want to try and maintain or build one, even if someone handed me all the parts and blueprints and a bunch of engineering apprentices to put it all together. Yet that kinf of approach is supposed to work in the enterprise? Which brings me back to Bill, as he points out:. > When Joel Spolsky talks about [Leaky Abstractions](http://www.joelonsoftware.com/articles/LeakyAbstractions.html), he’s talking about the situation where an underlying machine, one which you should ideally pay no attention to, pops through your present machine into your coding reality, Lovecraftian style. The word we use to describe this hiding of machines is "transparency", which is one of those technical terms that is correct, but bone-headed. Most people see the word "transparent" as allowing you to see through to something, not hide it. What we really mean here is "opacity", the ability of one machine to hide the fact that it is implemented in terms of another machine. It’s when the underlying machine (or machines) seep through that there \*is\* transparency.That’s when the leaky abstraction occurs and problems begin. While I have respect for Anne I do wonder, and perhaps worry, about industry analysts and our love for abstractions. I am one of the most abstract thinkers I know, everything fits into patterns, what is systems management but business intelligence and workflow for IT, and on, and on? But I am not a coder. Not even close. I am just a guy that would like to have one tenth of Tim O’Reilly’s [unerring pattern recognition radar](http://switch.sjsu.edu/nextswitch/switch_engine/front/front.php?artc=268). **Industry analysts are not practioners** – which is why we need to be more wary than most about drinking the coolaid, let alone mixing it, and having a vested interest in it. At RedMonk we talk to a lot of developers because we believe they often have insights and experience that architects, CIOs and vendors don’t. Stephen says its [signal to noise](http://www.redmonk.com/sogrady/archives/001312.html). Its why I think [SCA has a lot to prove](http://www.redmonk.com/jgovernor/archives/001140.html). I am not saying that RedMonkers don’t have prejudices (anyone for DRM?), and I strongly approve of Anne’s examplary [declarative living](http://www.redmonk.com/jgovernor/archives/001313.html) approach: we now know what her prejudices, or what she calls "vested interests", are. When an enterprise or vendor talks to Anne about web services and SOA, they should know what they are getting. That is goodness. They can tweak the semantic volume dial accordingly. I do believe that analysts, people like me or Anne or [Daryl Plummer](http://www.redmonk.com/jgovernor/archives/001376.html) need to keep listening to that little voice in the back of the head saying "come on – give me something more concrete to work with." People out there, our customers, and our customers’ customers, need to get things done… how can we best help them? With taxonomies and wordgames, or advice based on what the practitioner state of the art is? I am an abstract thinker but that doesn’t mean I have to, or should, trust abstractions. To be fair to Anne the blog entry I link to is generally well thought out, and makes the right noises about plain old XML (POX), Representational State Transfer (REST) and so on. But I am identifying a pattern… something industry analysts, and consultants too, need to be careful of. Our models of the world suffer from leaky abstractions, just like technical architectures do. The question is do we then delve into understanding why, or do we sweep the exceptions under the carpet? Good analysts will go for the former, hacks will choose the latter. We must beware falling in love with our own oh so elegant models of the world. Real life is messy and sloppy and all the better and more interesting for it. Life is loosely-coupled. Our models need to be. Tags: [industry analysts](http://technorati.com/tag/industry+analysts), [Burton Group](http://technorati.com/tag/Burton+Group), [Anne Thomas Manes](http://technorati.com/tag/Anne+Thomas+Manes), [WS-I](http://technorati.com/tag/WS-I), [Cote](http://technorati.com/tag/Cote), [RedMonk](http://technorati.com/tag/RedMonk), [declarative living](http://technorati.com/tag/declarative+living), [Leaky Abstractions](http://technorati.com/tag/Leaky+Abstractions), [Bill de hO’ra](http://technorati.com/tag/Bill+de+hO%27ra)