Quoderat

From the leader in this week’s Economist:

“Financial progress is about learning to deal with strangers in more complex ways.”

s/Financial/Technical/ and it applies just as well. What else are we doing in tech, if not figuring out ways for strangers to deal with each-other? Sometimes we focus on designing safeguards, like firewalls or spam filters, and sometimes we focus on creating opportunities, like social networks or source code repositories.

Update: the site shopping cart is broken, and doesn’t properly remove items from the total owing — too bad.

Here’s one easy way: via TechCrunch, Deutsche Grammophon, the gold standard in renaissance/ baroque/ classical/ romantic/ orchestral/ opera/ etc. music (often confusingly referred to collectively as “classical”, roughly equivalent calling all popular music since 1890 “rap”), will start selling their catalogue as unprotected MP3s at midnight German time tonight (6:00 pm in New York City) at their new site dgwebshop.com.

As a teenager in the late 1970s, I used to visit the House of Sound in Kingston (Canada), where they had thousands of DG records — probably most of the catalogue — packed in tight on on shelves lining a wall of the store. I couldn’t always afford them, but I loved being able just to pull them out and take a look at the covers of the different famous recordings. These days, the so-called classical music section of any but a couple of specialized stores in big cities like New York or London have maybe one or two rows of worthless classical-pop compilations hidden behind the DVDs of TV series nobody watched in the 1980s — no wonder people don’t shop at record stores any more.

We tech types have been claiming for a while that music companies could make more money selling unprotected digital music, so here’s the test. I plan to give them a lot of my own money if the site actually works, though I should note a couple of caveats:

1. Many current DG buyers are audiophiles who won’t be satisfied with the sound quality of MP3s (which are optimized more for boom-boom music), so this will probably open a new market for DG rather than leaching their current one.
2. DG’s market is mostly affulent people outside the intense social environment of high school or university, so people will be less likely to share these MP3s — and even if they do, it will probably just act as a promo for the higher quality recordings.

I hope the site can handle the traffic. Rock on, Deutsche Grammophon!

Summary: Perhaps the women who don’t choose computer programming are making a good choice, especially with the deteriorating working conditions, stagnant or falling salaries, and offshoring.

Recently, we’ve had a few postings about women in computing (or the lack thereof) — see Bray, Wood, Tenison, and Bray (again), all ignited by a piece in devChix.

These postings all assume that we need to do something to pull more women into coding. Why? Do we think there are there lots of women would be happy coding, but aren’t smart enough or motivated enough to choose the right careers for themselves, or are too timid to deal with any barriers unless someone comes along and dismantles them first?

Lawyers force companies to write page after page of end-user license agreements (”clause xix: The said user hereby indemnifies ACME Widgets against any harm caused to his/her pregnancy by use of this spreadsheet”) and disclaimers (”ACME Widgets does not intend that this flight-planning software be used to plan an actual flight or for any other aviation-related or planning-related activities”). We live in a litigious society, so companies need to protect themselves from spurious lawsuits.

But is that true?

When I read blogs and other stuff written by lawyers, VCs, and other similar professionals, I’m usually struck by the lack of legal disclaimers — they don’t seem to worry so much when it’s their own necks on the line, or are satisfied with one very brief, casual-language disclaimer instead of pages of B.S.

That leads me to two questions:

1. Do disclaimers and long EULAs actually work? Does the amount of legal text have any correlation (positive or negative) with the likelihood of being successfully sued?
2. Is legal mumbo-jumbo something that lawyers push on companies, or something that paranoid company execs demand from their lawyers (maybe because everyone else has it)?

I’d be interested in pointers to any studies, etc.

Dare Obasanjo just put up a posting with the title Open Source is Dead. Dare does happen to be a Microsoft employee, but his posting is none of the standard anti-Linux/OpenOffice/Apache/Firefox FUD. Instead, he voices a question that’s been floating around for a while:

… how much value do you think there is to be had from a snapshot of the source code for eBay or Facebook being made available? This is one area where Open Source offers no solution to the problem of vendor lock-in.

Elliotte Harold is absolutely right when he suggests that people should leave Java alone. New technologies compete on features; mature technologies compete on deployment.

Let’s value our mature, middle-aged technologies for what they are, rather than destroying their dignity by pumping them full of features botox and slashing them up with plastic-surgery keyword changes to try to trick people into thinking they’re young and immature.

With some minor lapses, the W3C has done well avoiding the temptation to improve XML to death. XML is still, in every way that matters, the same as it was when the initial recommendation came out nine years ago — warts and all — and that’s why it’s so widely used. Sun should pay very close attention, since Java’s around the same age, and is deployed in many of the same places. The people who actually decide to use Java and XML to run organizations and do real work (not bloggers, but architects, project managers and even sometimes CTOs) appreciate them for precisely that stability and dependability.

Here are the top ten locations as of January 9 2007, according to Google trends:

1. Pune, India
2. Bangalore, India
3. Hyderabad, India
4. Chennai, India
5. Mumbai, India
6. Singapore, Singapore
7. Delhi, India
8. Tokyo, Japan
9. Chiyoda, Japan
10. Hong Kong, Hong Kong

Note that the top cities are all Asian. A search for “J2EE” returns almost exactly the same list. Now, compare the list for a representative new, trendy technology, Ruby on Rails:

1. San Francisco, CA, USA
2. Austin, TX, USA
3. Pleasanton, CA, USA
4. Seattle, WA, USA
5. Salt Lake City, UT, USA
6. Portland, OR, USA
7. Vancouver, Canada
8. Denver, CO, USA
9. Oslo, Norway
10. Auckland, New Zealand

This time, it’s 80% North American and 0% Asian, and more interestingly, all of those cities are west of the Mississippi. The easiest interpretation of this very small sample is that the Asian companies concentrate on established technologies that they can be paid for using, while the North American west coast companies are disproportionately interested in new, unproven technologies. What about a new technology that’s designed to work with an older one? Could we expect a mix of Asian and North American west coast cities? Here are the top cities searching for “XQuery”:

1. San Jose, CA, USA
2. Bangalore, India
3. Singapore, Singapore
4. Chennai, India
5. San Francisco, CA, USA
6. Mumbai, India
7. Pleasanton, CA, USA
8. San Diego, CA, USA
9. Washington, DC, USA
10. Hong Kong, Hong Kong

The implication of this very unscientific survey is that you can determine the relative maturity of a technology by looking at the weighting of search origins between western North America and eastern Asia.

Early in the week, I posted about the end of the Google search API, and speculated that — since everyone else tends to copy Google — it might be the start of a general trend away from open data APIs and in favour of server-side AJAX widgets. In response, Amit Kumar of Yahoo sent me an e-mail message (after failing to get past Spam Karma in the comment system for my blog):

You don’t have to worry. We just posted a blog entry on this topic. Yahoo Search APIs are going strong - we welcome developers to use our APIs.

http://www.ysearchblog.com/archives/000393.html

Amit Kumar
Manager, Site Explorer

Thanks, Amit. Fortunately, megginson.com isn’t popular enough that it will break Yahoo’s 5,000 queries/day quota.

SOAP, REST, JSON, XML, and Serialized PHP

Note that Yahoo has a REST interface that can deliver results in XML, JSON, or serialized PHP, so if people get tired of the REST vs. SOAP perma-debate, there’s some alternative material for you here (if you want a good roaring debate, be careful to avoid reading Tim Bray’s carefully balanced view).

[Update: hacking the Google Search AJAX API — see below.]

[Update #2: Don Box is thinking along the same lines as I am.]

[Update #3: Rob Sayre points out that there is, in fact, a published browser-side JavaScript API underlying the AJAX widget.]

Over on O’Reilly Radar, Brady Forrest mentioned that Google is shutting down its SOAP-based search API. Another victory for REST over WS-*? Nope — Google doesn’t have a REST API to replace it. Instead, something much more important is happening, and it could be that REST, WS-*, and the whole of open web data and mash-ups all end up on the losing side.

My biggest frustration with the current Web Services debate (triggered innocently in a posting by Don Box, with followups by nearly everyone) is the lack of verifiable information. We need a big, independent study to answer two important questions about each part of the WS-* stack:

1. Does it actually work as specified in each individual implementation?
2. Does it actually work as specified across many different implementations?

Any WS-* feature that receives a ‘no’ answer to either of these questions is excluded from the debate — WS advocates cannot credibly claim that WS-* is more appropriate for complex, enterprise interfaces unless the complex enterprise features actually work, portably.

On the other hand, any WS-* feature that receives a ‘yes’ answer to both of these questions needs to be taken seriously by the REST advocates. They’ve gotten used to throwing mud at WS-*, assuming that everything is broken; where the WS people have managed to get something working robustly and portably, let’s at least start by giving them the benefit of a doubt that they might have solved a real business problem.

Steven Levitt (of Freakonomics fame) has started a small controversy by casually mentioning that the Y2K crisis was a false prophesy (his more detailed followup posting is here; he also points to a paper that I didn’t bother reading, but probably does a better job than my posting of going over the issue).

While I never advertised myself as a Y2K consultant, I made money from the Y2K panic like everyone else in IT — even if I didn’t do Y2K projects directly, systems were being replaced early because of Y2K, IT departments were getting bigger budgets and spending on whatever they wanted, etc. And like many (most?) people reading this weblog, I went out of my way to try to explain my customers at every opportunity why the Y2K threat was exaggerated.

The logic was simple: the scare stories in the press talked about everything shutting down at midnight on December 31 2000, but in fact, times and dates in IT systems are much more complicated than that: information and events go through lifecycles that have starts, ends, and often many stages in-between. Here are some examples:

• If you took out a 20-year mortgage in 1980, the expirty date would have been 2000.
• If you were 55 in 1990, you would have been 65 in 2000.
• If you received a new credit card with a five-year term in 1995, the expiry date would have been 2000.
• When your credit card bill arrived on 15 December 1999, payment was probably due in 2000.

So how many of you received notices in 1981 that your mortages were 81 years overdue? Or how many of you received pension benefits for 156-year-olds in 1991? How many of you found that your credit cards were declined in 1996 because they were 96 years past expiry? Or how many of you were charged 99 years’ interest for an unpaid credit-card bill in 2000?

Of course, some of these things did happen to some people in the decades leading up to Y2K, but only very rarely — rarely enough, in fact, that every case was considered newsworthy. 2000 was going to be the peak of a curve that started decades before and ended decades after, but since the curve was still so close to zero by the 1990s, it was obvious to anyone who cared to spend time thinking (even a statistical numbskull like me) that the Y2K consultants screaming doom and gloom were either not fully competent or not fully honest. It was important, of course, to check the most critical systems, like hospital equipment or nuclear power plants, but Y2K was hardly going to be a real operational problem for most organizations.

Those same consultants defend themselves now, of course, by claiming that they averted a catastrophe, but that is trivially easy to disprove — countries that spent very little on Y2K preparedness, like France, had no more problems that countries that spent a lot, like the U.S. and Canada. Of course, France benefitted from some spill-over from the North American IT work, but there still should have been a significant, measurable difference between the two. There wasn’t. QED.

A couple of times every month, I open all the bills, bank statements, investment statements, and government correspondence for my three (!!) corporations and blast through the paperwork (somehow, I always seem to open cheques from customers a bit more promptly). I’ve read marketing books that suggest businesses should use invoices and other business correspondence as an opportunity to market to customers, and the banks, phone companies, and even the government have taken this to heart — when I open a typical envelope, I’ll pull out a 1-2 page statement, then dump the envelope and several pages of brochures and newsletters into the recycling pile.

Am I an anomaly for not reading those? I discard them just as fast as I discard spam email, except that in the case of spam, I at least have to scan the subject lines first. For the junk inserts, all I have to do is feel the glossy paper under my fingers, or catch a glimpse of a smiling model staring off the page, and my arm reflexively tosses them; even easier, once I’ve pulled out the actual statement or invoice, I know that everything else is junk, and don’t need to examine it at all.

How are marketers ever going to reach people when we’ve developed such good, and even casual defences against them, both online and in print?

In L. Frank Baum’s book The Wonderful Wizard of Oz (Project Gutenberg), the Tin Woodman was originally a human named Nick Chopper. In an effort to prevent his marrying his sweetheart, the Wicked Witch of the East cursed his axe so that it would cut off part of his body every time he tried to chop wood. Nick lost his limbs one by one, only to have them replaced with metal versions by a friendly tinsmith. Eventually he lost his head and trunk as well, and had them replaced with tin in the same way.

Buy or build?

Nick’s story might sound painfully familiar to anyone who has spent time working with IT in large enterprises or government. Big organizations will buy a huge, off-the-shelf software system in an attempt to save the cost and risk of building their own, only to replace one part after the other because of lack of scalability, bad performance, bugs, or missing features. They end up with a system that they’ve built almost entirely themselves (at perhaps double the cost of a from-scratch system) but still have to pay royalties to an outside vendor to use.

How to avoid building your own Tin Woodman

Why does this happen? In principle, buying instead of building is a great idea — it lets a company share development costs with many others while concentrating its limited IT resources on its core specialties. This approach works, however, only when a product does something that is well understood and widely implemented (i.e. it’s a commodity). When considering an OTS product instead of building a system from scratch, a company should ask itself two questions:

1. Do we have a choice of more than one comparable product (preferably following the same open standards)?
2. Is this particular product already in full-scale production use at at least two or three sites that do the same kind of business, at the same volume, as we do?

If the answer to either of these questions is no, then you’re looking at a potential Tin Woodman: you’ll probably end up chopping off one limb at a time and rebuilding the product yourself, piece by piece. That’s not always a bad idea — companies will often choose to outsource R&D by funding the initial development of a product at another (usually smaller) company and serving as the launch customer — but in those cases, both management and IT know what they’re getting into, and there’s no expectation of simply installing the software, doing a bit of configuration and testing, then going into production in six months.