James Governor's Monkchips

Why industry analysts, more than most, should beware leaky abstractions

Share via Twitter Share via Facebook Share via Linkedin Share via Reddit

Proud new dad Bill de hO’ra was talking about programming languages on his blog and it got me to thinking about what worried me when I read that Burton Group‘s Anne Thomas Manes is proud of mixing the enterprisey coolaid we know as WS-*.

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, 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, 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.

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. Its why I think SCA has a lot to prove.

I am not saying that RedMonkers don’t have prejudices (anyone for DRM?), and I strongly approve of Anne’s examplary declarative living 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 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: , , , , , , ,

9 comments

  1. I still prefer “transparently” because I think of it like looking through a window to your end result… you can see it just happen and there’s no dirt in the way. But I get your point.

    I do think that auto-generating code and hiding certain details behind libraries or frameworks or higher-level languages are two different things. I hate, hate, hate auto-generated code possibly more than Cote’ does because I had to struggle through two years at Oracle with their tools that nearly demand it and I had to manage developers who only wanted to generate code, not write it themselves. That sucked. But, as Cote’ mentioned in his article, you can abstract things without going to a dumb operator approach, as when programming moved up from assembly language to C, then to dynamic languages like Python.

    I suspect you are right, though, to question the other Anne’s assertion that WS-* can overcome it’s enterprisey nature. Everyone was all into CORBA too and now is anyone using it? Simpler technologies will rule. What those are, I don’t know–POX over HTTP, maybe.

    Anne looks like a really interesting, smart woman. I’m glad to have found her blog. Good introduction of oestrogen! (I have never seen that spelling… shocking, I tell you)

  2. >I have seen too many JEE apps that performed like dogs because the developer didn’t understand how databases work
    I know I shouldn’t but, I’m laughing really hard with this post.
    It’s not that it’s a funny post per si but, I see that my long standing fight against the world is broadening their arena.
    Don’t be to hard on Anne, it’s exactly the same error everyone that talks about “commodity Hardware” commits, it’s just applied to another aspect of I.T.
    I know, I’m laughing at other people misery and about a serious subject that leads to poor quality, higher exploration costs and, basically, to uphold all that I fight against in I.T.
    The cherry on top of the cake is that this argument is beeing held with technologies from Microsoft. The company that told us all that we didn’t had to know how to develop to be developers (Visual Basic), the company who told us we didn’t had to be Sys admins to administer machines (Windows), the company that told us we didn’t have to understand RFCs to provide internet services (exchange) is now eating it’s own dog food.

  3. James, thanks for alerting me to this – you cover a lot of stuff here.

    Bit short of time to respond, but here are some bullet points.

    1. Software engineering is completely dependent on abstraction. If it wasn’t, we would all still be writing monolithic assember.

    2. Different people work at different layers of abstraction, with each layer making the job of those working above easier.

    3. In my experience (assember programming upwards), if you are working routinely at any layer of abstraction, you can generally do your job better if you understand (and have access to) the layer below.

    4. However, I am a strong believer in incurring extra work/complexity by exception. While you might know that a the code generated by a tool is sub-optimal, it is often good enough for most things and you only bother to drop down a layer when it really matters (e.g. for performance reasons or to do something not defined at your default working layer).

    5. If you find yourself dropping down too often (e.g. more than 10-20% of the time), you then make a judgement as to whether you make the lower layer your default. Impossible to generalise here – depends on the job at hand as well as the nature of the abstraction layers and toolsets.

    (SWITCHING CONTEXT)

    6. Abstraction is an important part of communicating complex ideas that are founded on a lot of detail/complexity – that’s why it is an essential tool for industry analysts.

    7. I agree with you that industry analysts vary a lot in terms of real world experience, so it is always worth checking the CV or bio of someone, as well as how they gather their intelligence, as part of understanding the basis for their output.

    Bottom line. Abstraction is essential to human existence, and expecially software engineering and industry analysis, so arguing whether it is good or bad is not the point. The real discussion is whether the way in which the abstraction has been defined/implemented is appropriate, and because one way is good or bad in one situation doesn’t mean it’s the same in others.

  4. I don’t think there’s anything wrong with abstract thinking but it needs to be guided/constrained by a reasonable level of understanding with respect to what’s lying underneath.

    IMHO we have too many developers that want to ignore what’s underneath completely leading to all the bad things it does. Why they want it that way, I simply don’t know especially when they get burnt so many times as a result. You’d think they’d learn from their mistakes.

    In respect of WS-*, well relying on correctly functioning tools to hide a mass of complexity doesn’t appeal to me in the slightest. WS-* is hardly a good example of KISS which for the engineers amongst us should be more than enough of a warning that something is deeply wrong with this approach.

    Lastly, I applaud your posting – I think it’s high time that a lot of analysts looked in the mirror and accepted the limitations of their engineering knowledge and adjusted accordingly.

  5. Dan – re: “relying on correctly functioning tools to hide a mass of complexity doesn’t appeal to me in the slightest”.

    I lean in your direction as I started out my IT career as an enthisuastic amateur programmer before having that “trained” out of me 🙂
    I remember when I was first exposed to these new fangled relational database things after working on flat files and network databases, I spent days figuring our how, exactly, the query optimiser was coming up with its physical search strategies behind the scenes. People around me thought I was mad until the first RDBMS project we deployed ran into performance problems and that knowledge allowed us to fix things.

    What we need to bear in mind, though, is that the majority of developers do it because they get paid to – not because they are passionate about it or even interested in it. They may have started out that way, but many lose it and it becomes just a job.

    I think it is all too easy when having these discussions to focus on the passionate minority who really take pride in their work, rather than the grumpy clock watching majority.

  6. Anne: thankfully, I’ve never had to deal with auto-generated code. That means, thankfully for my sanity, I just hate the idea of it since I’ve never had to get my hands dirty with it. I’m glad you’re out of that muck youself 😉

  7. from an interview with Tim O’Reilly,
    http://www.regdeveloper.co.uk/2006/04/29/oreilly_amazon/

    “Early in the web services discussion, I remember talking with Andrew Layman, one of the SOAP architects at Microsoft. He let slip that it was actually a Microsoft objective to make the standard sufficiently complex that only the tools would read and write this stuff, and not humans.”

    I’d say they succeeded brilliantly..

    Beyond that, I work in tech support, and spend a significant fraction of my time debugging other products’ (not the ones I support) autogenerated code. Point, click, generate is great when it works: when it fails, a human has to fix it. Surprisingly few can. I’m the exception processor for all the times the WS-* standards aren’t clear or are misunderstood. I guess it’s good job security in a way..

    Ellen Ullman noted the phenomenon in the late 90s, when this particular balloon really started to go up: hideously complex underpinnings to apparently simple coding, it only works until it doesn’t, when you have to find someone with an inkling of what’s underneath.

    The Lovecraft allusion is exact, made me laugh out loud.

    Ph’nglui mglw’nafh Cthulhu R’lyeh wagn’nagl fhtagn
    Aaaaaaaaaaiiiiiiiiiiiii!!!

  8. I had a comment mostly typed out, but then I figured I’d refresh to see what people’d written since — and found that all my points had been stated much more eloquently.

    I forget who said it, but I was once told that it takes more brains to fix bugs than it does to code, and that therefore if one codes at the limit of one’s abilities, the resulting bugs are *by definition* unsolvable. Keep it as simnple as you can, please, but TELL ME what complexity still remains. Hiding things is just going to puzzle me when it breaks…

  9. Hmmm. Your post “hints” that there are many architects you talk with that don’t actually code nor have a technical background in order to understand the WS-* stuff.

    Maybe the problem isn’t with Anne Thomas Manes but the ability of architects in corporate America. Would love for you to analyze us and uncover both positive and negative patterns…

Leave a Reply to Jaime Cardoso Cancel reply

Your email address will not be published. Required fields are marked *