May 14, 2008
Things That Everybody Knows
I saw an article today about how the Smart ForTwo (that tiny car you see around) had earned top marks in safety tests conducted by the Insurance Institute for Highway Safety. Despite this, the Institute decided to disqualify the car from potentially earning its "Top Safety Pick" designation because it is just too dang small. "All things being equal in safety, bigger and heavier is always better," says the president of the Institute.The idea that bigger, heavier cars are safer is something that everybody just "knows". The fact that it's actually false doesn't seem to matter much. Malcolm Gladwell pointed this out a few years ago (he even quoted Clotaire Rapaille!). It's true that in a collision between a small car and a large car it is safer to be in the large car, but small cars do so much better at avoiding accidents that you are much safer in a small car. The result is that the driver of a Volkswagen Jetta, say, is about half as likely to die in an accident as the driver of a Ford Explorer. So now we have the president of the Insurance Institute for Highway Safety, who even a hardened cynic would presume is trying to save lives, instead giving advice that will cost lives, just because he is going with a fact that everybody "knows".
Here's another fact that everybody knows: applications are migrating from the desktop to the web. It must be true because I keep reading it everywhere, for example in this Business Week article about Microsoft's battles with Google: "So far, the shift to online software is more of a drip than a flood. The programs often don't work as smoothly as, say, Microsoft Office, and they can require some tech savvy to use. But the shift seems sure to accelerate in the years ahead." The shift is sure to accelerate--just like it's sure that big heavy cars are safer than small light ones.
Let's draw an analogy. Imagine that public transit were free, like it should be. Now consider public transit vs. cars. Public transit (in this scenario) doesn't cost anything because it is paid for by a combination of ads and other sources of money that exist for their own purposes (such as government subsidies designed to reduce road maintenance costs). Public transit also doesn't require the user to do a lot of upfront planning, such as buying a car--they just hop on when they need to go somewhere. And at first blush, public transit looks a lot like what cars provide--it takes people places without undue exposure to the elements. This starts to look like a classic Innovator's Dilemma, with car being pushed hopelessly upmarket by current owners' incessant demand for better cupholders, allowing the "good enough" public transit to displace it.
So free public transit will displace cars, right? Of course people know it won't, and Toyota would not respond to the notion of free public transit by investing heavily in its own bus service; executives know that although on the surface free public transit looks better than a private car, if you dig a bit deeper you will find a variety of ways in which cars are better--enough that you know that in most cities, public transit adoption will hit an upper limit fairly quickly.
So now you have free software, which is supported by ads and other money sources, and doesn't require any upfront planning--the user can go to the website whenever they want (they can also save their data online, but this is a feature that a standalone app could offer fairly trivially). And on the surface, a word processor on the web looks a lot like a standalone word processor. But my feeling is that when you dig deeper, you discover a bunch of reasons why a standalone word processor is actually vastly superior to a web-based one, and although the web-based one will gain some adoption, it will never replace it. But, as often happens with the tech industry, people writing about software don't seem to have the equivalent of the gut feel that would cause any automotive writer to reject the idea that public transit could displace the private car. The hue and cry about the lightweight-application-with-data-stored-centrally replacing the standalone application is now well into its second decade; I expect it to continue to be something that everybody "knows" for the foreseeable future.
Posted by AdamBa at 10:40 PM | Comments (2) | TrackBack
May 06, 2008
"Hard Code" Kerfuffle
As I mentioned a little while ago, Eric Brechner's "Hard Code" column is now a public blog. This means you get a bit of a glimpse inside Microsoft in a public forum. Eric writes in his own inimitable style in order to provoke discussion, an area that he has certainly succeeded with his most recent column about recovering from errors.
First of all, ANY discussion of errors/exceptions/asserts/etc will generate controversy because it's an area where everybody seems to have an opinion on the right way to do it. Like all programming opinions, it's based in large part on the previous formative or traumatic experiences of the individual. Since we've all had different experiences we all have different opinions, and since we're programmers we have zero inclination to believe that differing opinions have any merit.
If you want to follow the argument along at home, it helps to know who the people involved are:
- Eric Brechner: aka I.M. Wright, Director of Learning and Development for Engineering Excellence, which means he owns the various different discipline excellence teams (as in Dev Excellence, Test Excellence, etc).
- Alan Page: Manages the Test Excellence team, reports to Eric.
- Alan Auerbach: Works on the Dev Excellence team.
- Larry Osterman: Way oldtime Microsoft employee and blogger.
- Kinshuman: (I assume it's the same guy) Works on Watson at Microsoft.
- Various other people: Don't know who they are.
There's also me, who manages the Dev Excellence team, thus reports to Eric and is Alan Auerbach's manager.
OK, so the fun started when Eric wrote his column saying that letting Watson catch exceptions was bad, instead you should handle them and crash. Larry blogged that this was a really stupid thing to say, and Kinshuman concurred in a comment. Alan Auerbach jumped in to defend Eric and also state that asserts are bad, Alan page replied and said that asserts are good, then Alan and Alan got into a brief back-and-forth on that.
Most of the arguments are of the ships-passing-in-the-night variety. Larry is saying it's bad to catch all exceptions; Eric is saying it's bad to let all exceptions through. These aren't contradictory positions. If you have spent a lot of your career working in an error-code-returning environment (like Larry, or Joel Spolsky, or Raymond Chen, or me) you probably have a natural bias against structured exceptions, but they are a fact of life in some environments (like .NET). But the more relevant fact here is that most people seem to have an argument pro or con exceptions that they deploy whenever they get a whiff of a discussion on the topic, and not much Socratic dialogue ensues.
Eric made a side comment about asserts in his article ("It's like the logic behind asserts—the moment you realize you are in a bad state, capture that state and abort") which misrepresents what asserts are for ("capturing the state" yes, "abort"--with the implication that it's similar to throwing an exception--no) although I think he threw that in there without really thinking about it. But it led to an interesting argument between Alan and Alan: are asserts good or not? I always liked asserts because I worked on networking code and an error might only occur once in a blue moon, so I wanted to break into the debugger when it happened; Alan (Auerbach's) assertion that you don't need asserts because you can set a breakpoint only holds true if you work on reproducible bugs, and I used to scoff at people like that--how hard can fixing your bugs be if every one of them repros on demand? But now that I think about it, relying on any kind of stress failure debugging to catch your errors is pretty outmoded. If I were writing a network protocol today, the first thing I would do is write a fake version of the layer below me that did odd things on demand, and next I would write a fake version of the layer above me that did odd things on demand, and then I would beat on my protocol with this in ever-more-interesting configurations. In such an environment all of my crashes *would* be reproducible and I could set breakpoints as needed. It's funny because I definitely thought of writing automated tools for stress (when I wrote my first NT network card driver in 1990 I also wrote a packet-blasting-and-counting protocol to help test it, which wound up becoming part of the network driver development kit) but never for causing the unexpected timing and dropped packets that lead to those hard-to-debug problems in protocols. I guess I have learned something in 20 years.
Posted by AdamBa at 10:09 PM | Comments (7) | TrackBack
