Recently Alex Payne of twitter posted Mending The Bitter Absence of Reasoned Technical Discussion, talking about the hysterics technical people get themselves in online. (Not so much in person, as he notes, since most people have trouble being such assholes face-to-face.) He was responding to quite a few angry posts about his discussion of Scala, focusing on a perceived slight against Ruby regarding performance and scalability.
I didn't follow the whole thing, but someone on twitter (!) brought up this today: Twitter: blaming Ruby for their mistakes?. In it the author (Tony) takes twitter to task for not using JRuby (because of their use of another JVM language) or other opensource/commercial message queueing systems (because of their roll-your-own). He attributes their decisions to NIH and gets quite snarky. Tony seems to have a good technical head on his shoulders, so we can't just attribute this to uninformed evangelism either.
There are quite a few comments on the blog, and to their credit a number of twitter folks chime in and respectfully let Tony know among other things that yes, indeed they tried other MQ systems, but those didn't work because of conditions unique to services at twitter's scale, or some other conditions that make up the 95% of backstory we never hear even with detailed technical articles.
Tony followed up his post with another backing off a bit, though written with his assumptions transcribed in the passive voice. (That's more crow eat than most people eat, so give him credit.)
In Alex's article he runs through a couple of questions you should ask before posting in anger. Here are a few applicable to this:
4. Do you have any first-hand experience with those technologies operating at the scale being discussed?
5. Have you contacted the individuals involved in the discussion for further information before making assumptions about their findings?
7. Are you addressing your peers with respect, courtesy, and humility?
To his 8 I'd add another (really a clarification of 7):
8. Are you assuming malice or incompetence where none might exist?
It's a good rule of thumb in many other situations as well. In fact, my post a couple days ago <a href=/2009/04/07/things_to_learn_from_legacy_code.html">on legacy code</a> discusses this implicitly -- the word "legacy" is often used to tag systems where the developers "did stupid stuff". But in doing so we're assuming incompetence where instead maybe there were terrible requirements, or a hostile customer, or a toxic team member, or any number of other things that can drag a project down.
A number of the twitter commenters said, "Hey, give us the benefit of the doubt." I don't see anything wrong with making that the rule, verifying as necessary. Put another way, there's a big difference between:
NIH ran rampant at twitter, they didn't even look at RabbitMQ!
and
I wonder how twitter's needs varied from RabbitMQ's strengths that they couldn't use it?