Steve Vinoski's Blog

As an author I don’t expect everyone to like what I write or agree with everything I write. I’m always up for receiving constructive criticism, as it helps me improve my writing, and when carried out with a positive mindset I think it helps everyone involved in the dialogue learn something.

Unfortunately, not all reviews are constructive, and those that aren’t can be hard to handle. I don’t know why some people have to resort to name calling and harsh words if they have a technical disagreement with you; perhaps those folks lack emotional fortitude and feel big when they hide behind their blogs or email, or maybe they don’t realize how foolish their own words make them look. If you’re an author faced with such a review, do you sink to the level of the reviewer and fire back at them with harsh words of your own to try to put them in their place? Probably not, since that just makes you too look like a jackass. Do you just ignore them? Sometimes that’s the way to go, as you don’t want to encourage your new-found stalker to continue stalking you and getting off on having succeeded at trolling to gain attention. (I use the term “stalker” here because there are definitely people out there who seem to just sit and wait for you to publish something, anything, so they can immediately “review” it to prove to the world just what an idiot you are.) But sometimes ignoring the review is wrong, too, as it might make it seem as though you have no answers for the reviewer’s criticisms.

Steve Jones just published such a gray-area review of my “Convenience Over Correctness” column. I don’t know him but he’s apparently a dyed-in-the-wool SOA fan, so it’s totally unsurprising that he disagrees with me. I started to go through his review paragraph by paragraph and respond to each point, but I found that it wasn’t very productive, mainly due to the personal insults and attacks he decided to throw in, oh, every fourth line or so. I’ll therefore just look at three of his criticisms in response, and leave it at that.

First, Steve chides me for pointing out what he deems to be obvious:

So far these problems [with RPC-based systems] have been detailed [in the column] as

• Remote calls have more issues than local ones
• Remote transaction processing is a bitch

There are no other issues raised and both of these points fall into the “well duh” school of pointing out the obvious.

But then he says:

I’ve built distributed systems and I’ve had to manage teams who delivered the architectures I created and I’ll say that

• 60% of the people didn’t understand the challenges and wouldn’t have understood Waldo
• 30% would have read it and got it wrong
• 6% Understand the challenges and can make a decent crack at it with minor problems
• 4% actually understand what it takes

These two sections seem contradictory. How can Steve fault me for “pointing out the obvious” when by his own estimate only 4% of my audience actually understands the issues?

I know for a fact from my columns and my conference presentations that there is a great desire for this sort of information, and that not everyone truly understands the hard issues of distributed computing, so at least Steve and I agree on that. My preference, though, is to help provide that information and help raise awareness, whereas Steve’s seems to be to just assume everyone else is a “muppet,” thus enabling him and his other 4% friends to do all the heavy lifting and spoon-feed everyone else with simple frameworks they might, just might mind you, be able to understand.

This is elitism, pure and simple, and it’s an expensive and non-scalable model. It puts the self-proclaimed 4% experts in control and wastes the vast skills and talents of the majority.

Coincidentally, my September/October column is going to touch on this. It’s already partially written and is due in a few days, and while it’s not at all a response to Steve’s review, it will explain in part why elitist systems simply cannot, and do not, last. I’m sure Steve will completely hate it.

Then there’s this:

What a load of crap. Seriously this is an unmitigated pile of tripe in what it means to write distributed systems. It makes two basic errors

1. That the architecture and design of a system is focused on a programming language
2. See number 1

Ignoring the foul language and such, how can anyone claim to be an expert in real-world distributed systems development like Steve does, yet apparently be unaware of the various Java and C# systems out there, for example, that use special meta-language annotations to export and expose language features directly as distributed system features? There are many out there who think you just throw some annotations on a class and it magically becomes distributed — they think only within the confines of their language, and magic frameworks provided by the 4% experts like Steve make all the distribution work under the covers. (Steve claims this approach is necessary because it’s all that the other 96% are capable of understanding, but IMO it’s really just one of the ways the big vendors and big consultants can continue to relieve uninformed enterprisey companies of their money.) Criticizing the column on this basis simply shows that Steve, a self-proclaimed expert, is unaware of the language-specific distribution frameworks out there, which is odd given that they’ve been proliferating for years.

The only other particular issue I’ll remark on in Steve’s review is his idea that he could quickly cobble together some code in his blog to “prove” that RESTful systems can fit in a programming language, and thus also suffer from the “convenience over correctness” problem. The column already states that people are trying to do just that, but that from what I’ve seen they invariably run into problems with various REST constraints such as the hypermedia constraint. If it were so easy, Steve, we’d already be overrun with RESTful language frameworks. Thankfully, though, we’re not, because the two simply don’t mix conveniently, which is why I’ll continue to stand by what I wrote.

For many years I lived in the same enterprisey SOA world as Steve, and so the only positive thing I got out of his review was a reminder of how glad I am to be away from it. I met a lot of bright people there, don’t get me wrong, but I miss neither the elitism nor the “that will neither work nor scale within the enterprise, you complete muppet!” attitude that was doled out when anyone dared make a suggestion that might actually improve things or threaten the control held by those elite 4%. Thankfully, though, that culture can’t last forever.

But then again, what do I know? I’m just one of the 96% muppets.

Stefan Tilkov‘s latest InfoQ article, REST Anti-Patterns, is simply outstanding. It covers all the bases. While it’s a great read for anyone doing RESTful service development, it’s especially suitable for developers who’ve already studied the fundamentals of REST but are still struggling to put them into practice, and also for developers who’ve done a lot of browser-focused web development but not much application-to-application web development.

My latest Internet Computing column, “Convenience Over Correctness,” (PDF) is now available. It continues the exploration of problems with RPC-oriented distributed programming approaches that I’ve been writing about in each of my three prior columns this year, as well as in columns from years gone by and in the erlang-questions mailing list.

For years we’ve known RPC and its descendants to be fundamentally flawed, yet many still willingly use the approach. Why? I believe the reason is simply convenience. Regardless of RPC’s well-understood problems, many developers continue to go down the RPC-oriented path because it conveniently fits the abstractions of the popular general-purpose programming languages they limit themselves to using. Making a function or method call to a remote or distributed function, object, or service appear just like any other function or method call allows such developers to stay within the comfortable confines of their language. Those who choose this approach essentially decide that developer convenience and comfort is more important than dealing with hard distribution issues like latency, concurrency, reliability, scalability, and partial failure.

Is this convenience for the developer the right thing to focus on? I really, really don’t think it is. There are ways of developing robust distributed applications that don’t require code-generation toolkits, piles of special code annotations, or brittle enterprisey frameworks. Perhaps the wonderful programming language renaissance we’re currently experiencing will help us to finally see the light and put tired old broken abstractions like RPC permanently out to pasture.

Looks like Progress is going to acquire IONA. Probably a decent deal for both.

I recently returned from giving two talks at each of the Brisbane and Sydney JAOO conferences. JAOO has long been my favorite conference, and even though this was the first time JAOO was held in Australia, my understanding is that overall it was quite a success. There were a couple hundred attendees in each city, and I heard a number of attendees echo something along the lines of “we really need developer conferences like this that aren’t marketing and aren’t academic.” That’s precisely why I like JAOO so much — almost all of the JAOO speakers are practitioners themselves, so as a developer you get a lot of well-grounded useful info rather than product pitches or unproven research.

My talks were “Building RESTful Services with Erlang and Yaws” and “Multilanguage Programming.” For first-time talks both went OK, but they could have been better. The biggest problem with both was that I already had too many slides for each one for an hour but when I got there I learned that a scheduling mix-up had reduced the presentation time slots to only 45 minutes, which then meant I had way too many slides for each talk. The first talk tries to cover a lot of ground, for example, and it’s hard to remove any of it and still have it make sense. Oh well. I warned the attendees up front about the problem, and since I got reasonable reviews for both talks I hope that means I left the attendees with some useful info.

There’s talk in the blogosphere of a strong revival in interest in programming languages, and I’d have to say there’s definitely something to that notion because I didn’t expect so many would be interested in the multilanguage programming talk. I guess I expected to encounter some defensive dyed-in-the-wool “X” programmers, where “X” often seems to be Java, who would just argue that multilanguage programming is a bad idea, but there were none. Instead I was encouraged by the number of developers who came to the talk and seemed truly interested in the idea of learning and using multiple languages in order to do their jobs in the best possible way.

Anyway, I strongly recommend that you go to JAOO Aarhus if you can.

Next up: Erlang eXchange in London, which I also strongly recommend. Overall it looks like a very strong program, and I’m really looking forward not only to giving my “Enterprise Integration” keynote there, but better yet getting to meet more folks in the Erlang community in person. I hope I’ll see you there.