In this morning’s issue of his monthly Crypto-Gram newsletter, Bruce Schneier points to a famous analysis of the used-car market to explain why bad products crowd good ones out of the market when the sellers know more than the buyers. "How do you solve this? You need what economists call a ‘signal,’ a way for buyers to tell the difference," Bruce observes.
When I hear the word "signal," I have to admit that the first thing that comes to mind is not economics — or even ham radio, despite my 38 years on the air — but the programming use of that term in C, in Perl and in other such contexts. Even better is the much higher-level use of signaling concepts in a modern workflow and approval capability.
Applications that run in isolation, started by a command and ending when they’ve put out a batch of results, are so last century: what’s interesting today, and even more so tomorrow, are software agents that are always observing the state of play and taking action when conditions require. It’s the difference, if you will, between American football with its set plays and what the rest of the world calls "football" with its continuing action.
Going back to Bruce Schneier’s reference, though, there’s a second key point to be made. The vicious circle that degrades free-market behavior is driven by asymmetry: that is, by the fact that when sellers know more than buyers, the buyers have to make assumptions based on average product quality. Lacking a way to know what’s better than average, they have no means of deciding what’s worth more.
How hard do programmers work at keeping themselves informed about their options? It’s harder to answer that question than it used to be. About ten years ago, I ran across statistics suggesting that the average programmer owned less than one book on the subject, suggesting that most people writing code for a living were about as "professional" in their pursuit as the typical truck driver. I’m not challenging anyone’s competence, but I am asserting that calling yourself a "professional" implies a commitment to continual learning and continual expansion of your skills.
Today, it’s harder to say who’s a programmer, and it’s harder still to assess the amount of effort that programmers put into extending their knowledge. Even rough statistics on programming book sales are hard to find, especially when topics like Microsoft Access get lumped into that category. Add in the amount of information that a programmer can consume without ever entering a bookstore, and any hard numbers become almost impossible to establish.
At least there’s one more opportunity on the horizon to learn more, referring of course to our upcoming Developer Conference in Santa Clara on the 21st. I’ll be there, listening more than talking, and I look forward to finding out what developers want to see on their menus of future platform options.