TV's Customer Effect

By way of Tim
Bray, I read Ole Eichhorn’s rant
about Longhorn. While I find it interesting and in places insightful, I think
he was a bit wide of the mark. The basic mistake he made is an extremely common
one: the assumption that all software is the same. Usually, this is coupled with “and
it’s the same as the software I write.”

I’ve fallen victim to this particular trap myself. One of the major foci in
my career has been the development of large-scale systems. As such, you’ll often
find me saying things like, “Extra database roundtrips are bad.” Or, “Avoid
building objects that map directly to tables and handle their own persistence.”
Both of these are good pieces of advice…if you’re building a system that
needs to scale. But of course, if you’re writing a system that’s going
to be used by ten people ever, you should ignore this and do what’s easy. And
lots of people are indeed writing these sorts of smaller systems, which is a totally
legitimate thing to do.

The keys to being a good architect are 1) knowing what the rules are, and 2) why they
are that when so you know when to ignore them.

So, does Ole have a good point about performance? Yes…if it’s going to
impact you. But in point of fact not everyone is writing the next version of Excel.
There are plenty of applications for which developer productivity is more important
than an extra 10% (or whatever) in response time. And of course the jury’s still
out on what the performance penalty will be. And of course it’ll be different
for every application anyway. But in any event I’d argue that there are at least
ten times as many departmental one-off applications being written as there are commercial
shrink-wrap ones. Whether or not these are “important apps” (Ole’s
term) sort of depends on where you sit.

But Ole’s bit does beg the question, “Is Microsoft right to continue to
emphasize developer productivity?” I think it’s obvious that they are
– the CLR’s big win is clearly this, and it looks like the Longhorn technologies
continue largely in this vein. But you have to ask, “Is this good for the users,
who outnumber the developers by some large factor?”

I don’t know the answer to that. What I do know is that it reminds me of another
familiar market: commercial broadcasting, particularly TV. I often wonder at how bad
broadcast TV is. Sure, there are some shows I like, but a lot of it sucks. There are
two conclusions I can draw from this: 1) that most people have taste that differs
from mine, or 2) the viewer’s preferences are not the controlling factor. While
the former is probably true, it’s the latter factor that’s interesting
here, because from a commercial standpoint, it’s demonstrably true. Advertisers,
after all, pay for the programs, not viewers. So the broadcasters are directly beholden
to advertisers, but only indirectly beholden to viewers. And note that for
the networks where this is not true, like HBO and public television, we get a noticeably
different spectrum of programming.

In Microsoft’s case, we actually have the opposite correlation. The revenue
comes from products like the OS and like Office, and not from Visual Studio.NET and
the CLR. Sure, there’s a linkage – developers create the software that
users’ consume, making the platform more attractive to said users – but
again it’s indirect rather than direct. I’m not sure what
this means…but I find it interesting.