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.

I finally got around to watching and listening to Bob Ippolito‘s “Exploring Erlang” video, and I don’t know of any more thorough hour-long introduction to the language than this one. If you’re interested in Erlang but are too busy or too lazy to read Joe Armstrong’s great book or any of the many papers and articles that describe Erlang, then Bob’s talk is for you.

A few interesting points for me:

• In a few places Bob mentions that while he finds Erlang syntax unusual it’s really no big deal, and you quickly get used to it. I can verify that he’s absolutely right. A lot of people seem to get really hung up on this issue; if you’re one of them, all I can say is that your concerns are very greatly exaggerated.
• Along the lines of the previous point, one of the questions Bob takes after his presentation is from a gentleman who says that his technical lead refuses to use Erlang — in a telephony application, no less — and that his tech lead rolled his own stuff for concurrency and interprocess communication. Hmm, I wonder if that technical leader’s initials are “N.I.H.” It would be interesting to see how well his solution could hold up in the environments in which Erlang has already well proven itself. Given all the attempts I’ve seen over my career at solving such things, many of them made by people who mistakenly think it’s not that difficult to get right, my guess is “not that well.”
• Bob mentioned that he finds Erlang to be a very small and thus easily learnable language. He’s absolutely right about that, too; I wish I could count the number of times I’ve said the exact same thing in conversation, in presentations, and in writing. Many people who come from Java or C++ or other general-purpose languages assume that languages need to be huge to be useful, so they assume that small languages must be toys, and they also assume any “real” language requires years to learn. How incredibly wrong they are.
• Bob keeps the whole discussion grounded by explaining how Erlang saves him and his team time and money. In case it’s not clear, he’s talking about actual time and actual money. He explains that he can serve millions of web requests per day from just a single machine (though he naturally uses more than one for redundancy and reliability), for example, and by mentioning the small size of his team — I think he said 8? — he hints at the productivity that Erlang affords. My experiences are, again, quite similar.

Coincidentally I also watched Jim Weirich‘s “Shaving with Occam” presentation from the MountainWest RubyConf 2008 held at the end of March, and was pleasantly surprised to find that he devoted a good portion of his talk to Erlang. He mentioned how it was like Lisp in the sense that it has a small core, simple rules for manipulating that core, and powerful abstractions for building new things from the simple rules and small core. Yet, I shouldn’t be surprised. I don’t know Jim at all, but judging from the dates he mentions in his talk I think his career spans around 30 years. It’s also pretty clear that he’s had broad and deep experience with many technologies during that time. From what I’ve seen, people like Jim who have an incredibly deep first-hand understanding of the utility and importance of simplicity, brevity, and powerful abstractions in software development seem to have no problem whatsoever quickly seeing and comprehending the immense value of Erlang.

You’re still not exploring Erlang? What are you waiting for?