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. ]]> http://www.proudlyserving.com/archives/2008/05/things_that_eve.html http://www.proudlyserving.com/archives/2008/05/things_that_eve.html Wed, 14 May 2008 22:40:21 -0800 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.]]> http://www.proudlyserving.com/archives/2008/05/hard_code_kerfu.html http://www.proudlyserving.com/archives/2008/05/hard_code_kerfu.html Tue, 06 May 2008 22:09:22 -0800 Donald Knuth Rips On Unit Tests and More, implying that the Lord of Algorithms thought unit tests were a waste of time. If you read the actual interview, you will see that Knuth is simply saying that in his own experience writing code, he has never found much use for unit tests.

My interpretation of this is that Knuth has never had to write a particularly large piece of software where he was not the only author. Because that is where unit tests can really help: preventing somebody from accidentally breaking somebody else's code when they make a change. If you are the only author, you may have a good enough idea of the code in your head to prevent such errors (although it would be somewhat conceited to think you would never do it accidentally).

Knuth's idea on how people should write code is an idea he came up with called literate programming, which involves creating a document that describes the code and also can have the source code extracted from it. Knuth introduced literate programming in a language called "WEB", which he used to write TeX (my father says that Knuth chose the term "web" because back in 1981 it was a three-letter word that had no existing computer-related meaning). Literate programming is not a bad idea, but the notion that it would solve modern programming problems is simplistic--unless you are only thinking about software written by one person (as an aside, there was somebody, I don't know who, who used to work in Engineering Excellence and misinterpreted "literate programming" to mean embedding comments in your source code that could be extracted by a tool to produce documentation--what programs like Doxygen and Sandcastle do. So in our slides there are various incorrect uses of the term, every time we talk about documentation generators).

In my class this week I happened to have somebody who worked with me at Softimage back in 1996, and we were reminiscing about some of the programmers who worked there. In particular, a couple of the key architects on the product were "lone wolf" type programmers who spent their time cranking out code and didn't interact with people much, except possibly to point out things they were doing wrong. This led to various zany designs and rules that didn't make much sense, but which it was a losing proposition to try to argue against (the most notorious of these was the stipulation that include files in C++ sources had to be alphabetized by filename; it's a strange enough rule that it's hard to think of a real-world analogy, but you might consider a university where you were required to take all your courses in alphabetical order by course name).

You still hear people gooing and gahing over programmers like that: "they don't talk to anybody, but they sure write a lot of awesome code!" In prior eras at Microsoft such programmers were celebrated, and then we went through a period where they were tolerated, but now I think the pendulum has swung, correctly, to view such people as negatives on a team.

Looking back we probably should have cashiered those guys out of Softimage, but from the inside it always seems like it's worth sticking with them in the short term because the temporary pain of losing them would be so great...but it's not worth it. Hatching a giant code egg all by yourself, even if it is "good" code (and it very likely isn't), just isn't a key part of being a software architect. The job is really all about helping others succeed, growing the skills of the team, representing your team in interactions with other teams, and so on. Sitting in your office with the door closed accomplished none of that. Arguably it would be a case of "what got you here won't get you there", except that in retrospect it shouldn't even have gotten them here.]]> http://www.proudlyserving.com/archives/2008/04/the_myth_of_the.html http://www.proudlyserving.com/archives/2008/04/the_myth_of_the.html Tue, 29 Apr 2008 21:46:18 -0800 I rented a car while I was here, figuring it would be entertaining (never haven driven on the proper side of the road before). I was concerned about remembering to turn into the correct side of the road, but that actually wasn't a problem--having the steering wheel on the other side was enough to remind me. I did have a few minor things that kept happening:

• I would drift a bit to the left of the lane--not into the next lane, but just a bit, I assume trying to compensate for a subconscious feeling that my body was in the wrong place.
• I kept reaching for the seatbelt on the wrong side of my body.
• When I wanted to in the rearview mirror, I always looked to me right, then wondered why the view out the side mirror wasn't what I was expecting.

A bigger problem was how narrow the roads were. On the way from my hotel to the training site I crossed the Chertsey Bridge, which was spot-on lovely, but was built in the 1780s and, as somebody put it, is wide enough for a horse and buggy to pass in either direction. Which makes it a bit tight if a lorry and a motorbus try to pass, or even two cars, if one of them is driven by an expat American trying to find second gear on his car.

The narrowness also made it hard to navigate because you couldn't stop for a second to look at a map without risking a head-on collision (not that such map-checking behavior is advised anyway). And it's a bit hard to navigate in general because street signs are a bit rare and the names change often anyway, so you have to follow the numbered roads, which follow more logical paths from town-to-town. But if you miscount at a roundabout and head off in the wrong direction, it can be very hard to figure out where you are, especially since the road numbers are only signed at roundabout exits. Furthermore at any given time there was some annoyed driver riding my bumper (the roads seem to alternate narrow and less narrow spots, so I think people hustle through the narrow spots to minimize their time spent in them). I wound up feeling a bit stressed most of the time I was driving, which I have not felt before, even in unfamiliar locations. On the first day I faced an oncoming bus on a narrow street, and had no choice but to put two wheels up on the opposing sidewalk, leaving me inches from the stone wall that conveniently bordered the road, for maximum claustrophobic effect. Nobody seemed to put out by all this, in fact there must be some unwritten rules on when you park your car half on the sidewalk and when you don't.

All-in-all I did enjoy driving in England. By the third day I knew where I was going and was passing bikers in front of oncoming traffic just like a seasoned Brit. And today I managed to make it back to the Avis rental return with the car and myself intact. The correct answer to all this might be "rent a GPS for the car", but that wouldn't be much fun, now would it?]]> http://www.proudlyserving.com/archives/2008/04/driving_on_the.html http://www.proudlyserving.com/archives/2008/04/driving_on_the.html Sun, 20 Apr 2008 06:04:47 -0800

(Of course I have Windows Update on; I don't think I could get away with having it off on the corporate network.) I found the message amusing, and I can understand the reason why it would be presented to me; but I can predict that other people would feel other emotions when they saw it.

There is actually a space below where you can enter a comment and send it in...since the message has nothing actionable in it (in fact I have no idea what it was about, the machine seems to be working fine) I'm curious what kind of feedback people send in.]]> http://www.proudlyserving.com/archives/2008/04/yes_no_or_somew.html http://www.proudlyserving.com/archives/2008/04/yes_no_or_somew.html Sat, 12 Apr 2008 17:35:11 -0800 In the course we talk about various ways to design your software so that it is easier to develop, easier to maintain, easier to test, and so on. The basic rule is to encapsulate variation, meaning to hide things that are different behind a common programming facade so you can treat them as the same. If you look at, say, the way a networking stack is built, your network transport uses an encapsulation that treats all network card drivers the same, and then the network redirector uses an encapsulation that treats all transports the same, and then the rest of the system uses an encapsulation that treats all file systems (which is what the redirector exposes itself as at the top) the same. If you burrow into the details of any of these components, they are using various encapsulations to treat timers and user data buffers and configuration settings and all that the same.

This is all fine and dandy and if you can come up with a design that nicely encapsulates your variation, you will have a piece of software that you can explain to someone else AND feel proud while doing it.

Then performance rears its ugly head.

It's not that performance is a bad aspect of design; in fact it's really the only aspect of your internal design that a user will notice. The problem is that performance directly contradicts ALL of the other criteria that make software "good". Software that is nicely encapsulated simply runs slower than software that breaks encapsulation. If you start out with a clean design and then make it run faster, then the result will be harder to develop, harder to maintain, harder to test, and harder to explain to someone else. It will be "worse" by any measure you can think of--except for speed. Now, speed used to be about the only metric we had for measuring software quality--but the industry has matured a bit. People program in C# instead of C, acknowledging that the result will run slower, but that all the other benefits are worth the tradeoff.

So that is the basic tension in software design: performance vs. everything else. Experience in software design is not so much about knowing design patterns and all that jazz; it's about knowing when to break your encapsulation to make it run faster, and when not to do that.

You would think, perhaps, that cleaner design would run faster. It seems like that should be the case--but it never is. This is one of the reasons that people rail against the perils of premature optimization. The nominal reason is that spending time optimizing early is wasted if the thing you are optimizing doesn't wind up as a performance bottleneck; but I think underlying that is the realization, conscious or unconscious, that optimization means making the code worse, so you should avoid it until you have evidence it is necessary. Of course many programmers think optimization is "cool", both on general principle, and because people can see the results; conversely they don't give two figs for any other aspect of code quality...you can guess the result.]]> http://www.proudlyserving.com/archives/2008/03/software_design.html http://www.proudlyserving.com/archives/2008/03/software_design.html Sun, 23 Mar 2008 19:24:36 -0800 One of the coolest things that's out there on the Internet is the availability of free geocoded satellite images, so you can simulate this experience anywhere in the world. I was in Las Vegas last weekend (for a hockey tournament, not MIX) and while I enjoy the view of the Strip from above, my favorite is sections like this, to the west of the Strip where people actually live (yes, people do live in Las Vegas):

View Larger Map

(I did this in Google because I couldn't get Live to give me a link; even with Google I had to hack up the URL it generated). One thing this view demonstrates is the complete artificiality of Las Vegas. When you look at Seattle from above you can imagine that some of the trees were there 200 years ago, and perhaps some of the lakes and rivers are close to their old boundaries; that road you see crossing between those hills might follow an ancient trail. But with Las Vegas, the mix of neatly arranged subdivisions and scrubby desert, with straight roads the peter into nothingness the instant they pass the last house, makes it clear that it's all fake; every blade of grass or piece of gravel comes from somewhere else.

I don't find this appalling at all; in fact I like Las Vegas a lot, both as a real place and an idea. The central notion of Las Vegas is that nothing is permanent, that the present places no limits on the future: what is is just another factor to consider when planning what will be. If there's already a casino on a spot where you want to build your casino, don't worry about it too much. All it means is that the cost and time of your project has to include knocking down the existing casino.

I think this is a valuable lesson for software developers. It's the same thing that YAGNI is about, trying to get developers to be more agile. Too often we get hung up on the way our code is written when considering how to extend it; or we try to plan for the future in our initial design and wind up getting boxed in because we don't want to undo what we did once we figure out what we really needed. Las Vegas doesn't think like that. If a road has to go a certain distance to reach some houses, then you stop the road at that point; if in the future somebody needs to extend the road to reach some new houses, they can build it then (I'm ignoring the foresightful but anomalous planning of I-215 in this argument). Bellagio builds a monorail to the Monte Carlo, then has to trash it to build their new tower 5 years later. Could they have anticipated this? Possibly, but why bother; it's just something else to factor in when the time come. Microsoft is considering something similar, tearing down the ten-year-old Building 24 to make way for larger buildings. At first I found this "wrong" in a fundamental way: "We just built the thing, how can we consider tearing it down?" But if we need the space we need the space, and it shouldn't really matter if the building that is there was built last week or last century. That's Vegas-style thinking, which is what I like about Vegas: it's an agile town.]]> http://www.proudlyserving.com/archives/2008/03/the_agility_of.html http://www.proudlyserving.com/archives/2008/03/the_agility_of.html Sun, 16 Mar 2008 21:12:35 -0800 MSFTextrememakeover when Mini-Microsoft links to it, but lately it is showing signs of creating its own community independent from Mini. If you consider my idea of blog stages (toot, toot) the blog is currently in "storming" mode, but shows signs of moving to "norming", at which point becoming "performing" is just a matter of time.

For example, in February the site generated 60 user comments, or almost two a day, which is pretty good. It's roughly where Mini-Microsoft was in about March of 2005; by June 2005, riding a wave of froth whipped up by annual review season, Mini had started down the road to phenomenon-hood. It's true that it's taken MSFTem a year longer to reach that stage than Mini, but the trend is upward.

MSFTextrememakeover has an angle and some expertise (in analyzing financial results) and has lately moved into more general criticism of Microsoft. The author is also starting to adopt a more entertaining style, while maintaining a pretty steady negative attitude--what you might expect if Eeyore could break down a Form 10-K. Mini-Microsoft occasionally offers a glimmer of hope that Microsoft's future is not nasty, brutish, and short, but MSFTextrememakeover generally dispenses with that, which is a useful trait for a blog in the storming phase (if the blog becomes more popular, I predict it will soften a bit).

It occurs to me that there hasn't been much speculation about his/her identity. I sort-of assume he/she worked at Microsoft, but looking back over the posts I would suspect no, although they obviously are a shareholder and likely live in the Seattle area. If they don't work at Microsoft I suppose there isn't even any opportunity for a debate on the morals of what they blog about, but I will point out this article about Wal-Mart bloggers who are free, apparently with corporate blessing, to say whatever they want about the company on a corporate blog called Check Out ("Where the lanes are [gak] all open"). There are about 10 authors on the blog, covering gadgets, gaming, movies and other topics that appeal to people who get their news from blogs (plus Lawn & Garden, not sure what that is doing there). One blogger, Rand Waddoups, writes about sustainability, which is interesting because Wal-Mart is making a big bet on that. A quick glance at reveals few negative comments about anybody; Elmo, Playstation, Verizon, Danactive...they're all good. The most risque item there is a commentary about the upcoming U.S. tax rebate--written by Alex Cook, who also wrote the dubious comments about Vista (is he a Microsoft shareholder?). Still, I like the experiment; Wal-Mart at first tried the PR-driven shiny happy blog, but has now decided that this is the better way to go. ]]> http://www.proudlyserving.com/archives/2008/03/is_msftextremem.html http://www.proudlyserving.com/archives/2008/03/is_msftextremem.html Mon, 03 Mar 2008 21:20:05 -0800 Benicia-Martinez Bridge. It carries Interstate 680 across the Carquinez Strait, northeast of San Francisco, and is the bridge you would cross if driving from (say) Sacramento to San Jose. I know, you are all thinking, "If you insisted on detouring towards the Bay Area, how come you didn't head just a bit further west to cross the Al Zampa Bridge?", all I can say is that I was in a bit of a hurry (a poor excuse, agreed).

The Benicia-Martinez Bridge is now two bridges, with southbound traffic on the old bridge and northbound traffic on the new bridge, which opened last August after being under construction for several years (there is also a railroad bridge which sits between the two road bridges). I was looking at satellite photos of the bridge, and noticed that different sites captured different phases of construction of the new bridge.

First you have the Google Maps view, where about half the piers haven't been started. On Yahoo Maps the piers are mostly above the waterline. In the Live Maps image the piers are done and parts of the roadway are in place. Mapquest has the roadway almost complete. And on TerraServer the bridge looks finished (if you want to look at different systems, start with the WikiMedia GeoHack page for that location).

I was actually expecting that they would all be sharing the same satellite imagery, or maybe a couple of different sets; the fact that all 5 were different is surprising. And if you knew the details of when the bridge was constructed, you could actually tell pretty closely when each picture was taken.]]> http://www.proudlyserving.com/archives/2008/02/tracking_constr.html http://www.proudlyserving.com/archives/2008/02/tracking_constr.html Fri, 29 Feb 2008 22:13:24 -0800 http://eewiki and http://eeh, respectively).

The wiki is a wiki, whch means that anybody can modify anything at any time. It does track the corporate network login of the person making each edit, so outright defacement is unlikely, but other than that it's fair game, and if you make an edit it is immediately available for everybody to see (right now, most of the edits are done by people in Engineering Excellence; one of the things I've been doing to try to change that is have every class I teach make at least one edit to the eewiki, however trivial, so they get a feel for how easy it is). The wiki is very convenient place to put information, for example for any topic that we teach such as formal inspections, the eewiki page will have a section "teams at Microsoft using formal inspections" and we ask people to add themselves to the list if they are using them.

There is also the Handbook. This is a website running on technology developed within EE for the specific purpose of hosting the Handbook (the eewiki currently runs on FlexWiki). It has a sophisticated layering model where there is a base handbook, then teams can replace specific pages, or let them flow down from the base page, and so on down the hierarchy. Also, there is a workflow involved in making changes, in which they are shepherded through by people in EE (such as myself), submitted to a team of editors and content architects, and then updates are queued up and published on a regular basis.

It's the standard short head vs. long tail situation, and you may not be surprised to hear that on the dev excellence team, anyway, the eewiki is winning out. We do occasionally drive Handbook changes, and there are useful pages in the Handbook that I show off in class, but our go-to place for storing information is the eewiki. This includes both stuff that is internal to our team (such as outlines of courses under development) and material intended for the broader Microsoft audience. So the experience for somebody outside our team (but inside Microsoft, of course, since the eewiki is only available on the corporate network) is a mish-mosh.

I think a bit of it is that we're being lazy and don't want to deal with the Handbook workflow, so we make the quick eewiki edit without worrying whether it is the best experience for our customers. But I also think that there is something "developer-y" about favoring a wiki over something more formal (other teams in EE have different balances of wiki vs. handbook; I'm pretty sure the dev team is the most wiki-centric). The fact is that the wiki is a much closer approximation to how we write code. The trend in software development these days is to be more "agile" and empower people to complete things on their own, and the wiki definitely fits in that model better than the handbook. So for better or for worse, it's no surprise that we devs feel more comfortable there.]]> http://www.proudlyserving.com/archives/2008/02/the_wiki_and_th.html http://www.proudlyserving.com/archives/2008/02/the_wiki_and_th.html Tue, 26 Feb 2008 21:31:04 -0800 Quirks & Quarks (excellent show, by the way). This particular episode featured an interview with Gary Taubes, author of Good Calories, Bad Calories. Taubes, who is a science writer, not a diet seller, says that all the actual medical research he could find indicates that the way to lose weight is to cut carbs, and the prevailing advice to cut calories is based on a biblical notion that you need to suffer in order to lose weight.

I had heard this before; it's what the Atkins diet is based on. I had previously suspected, as I wrote a long time ago on a website far, far away, that cutting calories was the key to losing weight, and the Atkins diet was really just a clever way of making you consume fewer calories (by making you pay attention to what you were eating, mainly). But Taubes was saying no, that the "3500 calories is one pound" rule was a myth, and it really was about cutting carbohydrates, not calories.

At the time I had just signed up for my foray into acting, and I figured it wouldn't hurt if my character looked a little emaciated. So, I decided to try cutting out carbs, while eating whatever protein and fat I wanted, and see what happened. I didn't buy any books, just looked at nutritional labels and tried to get carb intake as close to zero as possible.

So what did happen? Well, I certainly enjoyed the delicious omelettes with prosciutto and bergenost (courtesy of Costco) that I would whip up in the mornings. And I was able to use the fact that I was conducting a scientific experiment as an excuse not eat a bunch of junk I didn't need to over the Christmas holidays. BUT, although I did lose about 5 pounds in a couple of months (with my carb avoidance trailing off gradually towards the end), I still felt like I was also eating less, in particular at work because I would wind up not eating half my meal, and also because I essentially cut out all desserts. So it really wasn't clear if it was the carbs or the calories. Also, although I wasn't overweight to begin with, there certainly was no "the weight just melts off effortlessly" effect. In the end, the experiment was inconclusive.

I did one other body modification for the play: I grew a goatee. Originally it was going to be a beard, but the director decided that a goatee would be better.

After the last show I shaved it off. This is the before and after view; to frighten the children I stopped at an intermediate point with just the mustache, which I don't think I would ever wear out in public:

]]> http://www.proudlyserving.com/archives/2008/02/body_modificati.html http://www.proudlyserving.com/archives/2008/02/body_modificati.html Mon, 25 Feb 2008 21:02:20 -0800 Certainly writing a service is different from writing packaged software, but within the realm of packaged software there are also huge differences. Writing a Windows kernel driver is very different from writing an Xbox game, but is it more different to work on a service? As with any software, when working on a service you have a layer above you and a layer below, and you stitch them together while implementing your requirements. You may have some different sorts of requirements, for example that the service can be upgraded without bringing it down, but packaged software also has a wide range of requirements.

I've been asking people about this and I haven't got back much that really felt "different". BUT there is one thing that seems to stand out that really is a change in thinking when working on a service: you have to expect and deal with failure.

If you're working on an Office app and you get a wierd error from the video display driver when trying to draw a graph, you will in all likelihood expose that error to the user: either by mysteriously failing, or by poppping up an incomprehensible error code. You may realize, in the back of your mind, that some very very small percentage of the time this will actually happen (a one-in-a-million Vista issue will still affect about 100 people), but you still view it as an unnatural event that you can't be expected to accomodate in your code (some errors, of course, are common enough to be handled, such as running out of disk space, but those are the exception, not the rule). So you let the customer figure out what to do (reboot, restart the app, whatever). I don't mean to make us seem callous or uncaring about user-visible errors; certainly you try to handle the common ones, but if you think of all the possible error codes that a Windows API can return, your code can only include specific responses for a small subset.

On a service, given the number of machines you may have in your data center, the distance that your data has to travel and the relative imperfection of the path (network vs. bus), and the knowledge that the customer has no ability to poke your computers, you know you have to handle failures gracefully--and that means ALL failures, not just the ones you can think of.

I consider this a mind-shift because it colors how you solve other problems also. A packaged software person who is given the problem of designing a system that can be updated on the fly may come up with a centrally managed system in which the remaining computers are notified when a subset of the data center is going to be offline, they then adjust to not even try to contact them, and then are told when they are back. So the machines go offline but in a controlled way and nothing unexpected ever happens. Meanwhile, somebody designing with the services "expect failure" mentality is going to architect a system that can adjust for machines disappearing and reappearing at any time, so their in-place upgrade solution can be to have the operators hit the power switch on the machines they want to upgrade, upgrade them, and then put them back in service.

I was thinking about this and I realized that my formative years were spent writing code for this kind of environment. I worked on network transports, and the entire point of a network transport is to recover from mysterious failures: dropped packets, delayed packets, duplicated packets, misordered packets, etc. The mainline path is easy; it's handling the errors that is all the work (I once wrote a sample network transport for the device driver kit that didn't handle any errors; it was about one-tenth the size of the real one). In retrospect I think this was great training as a developer, because it got me thinking in the "services mentality" way back when. And in the future, ideally all packaged software developers would borrow that approach from services, and use the expectation of failure as a way to engineer reliability into software that runs on just one machine.]]> http://www.proudlyserving.com/archives/2008/02/is_there_a_serv.html http://www.proudlyserving.com/archives/2008/02/is_there_a_serv.html Fri, 22 Feb 2008 19:35:30 -0800 Consider the first 3 questions on C++; obviously whoever wrote these had just spent some time reading the part of the manual that talks about structs, because the questions are: "What is the difference between class and a struct", "Why is a struct public", and "Can you inherit and have member functions in a struct". The correct answers are not, as you might suspect, "I don't know", "To confuse people who have figured out copy constructors", and "I'll say yes, because it sounds like a bad idea so C++ probably allows it" but actually have to do with the fact that a struct is public, to allow backwards compatibility with C. The problem with this type of questions in general is that they rely too much on knowing specific facts, rather than how willing and able people are to learn new things. And going beyond that, those specific questions deal with some arcana of the C++ language that few right-thinking developers would ever take advantage of. I mean, you have a struct which is like a public class, which is a dumb idea, and then you'll put member functions in it (so much for backwards C compatibility), which is even dumber, and then to top it off you'll subclass (or substruct, I guess) the whole thing? If somebody knew the answer to this question it might imply that they had actually written code like that...which might make me less likely to want to hire them, not more (then for extra measure, there are two other questions about dynamic casts and unions...it's like a police lineup of bad C++ techniques).

Most of the rest of the questions are like that; they ask about a single fact, many of which are esoteric--except for the ones that are trivial. For VB, the first question is "What is a method" (trivial) and the next one is "What are the four states a Form can have in Visual Basic?" (esoteric). For Java you have a question on what an interface is (trivial) and then one about .java files with multiple classes definitions (esoteric). Then there is this classic about SQL: "What is the difference between locking and deadlocking?" That last question reminds me of a quote from Jack Vance: "[he] was a man beyond her understanding; whether he were vastly more subtle than she or vastly more elemental, she would never know."

The problem with questions like that, especially the esoteric ones, is that getting them right or wrong doesn't mean much. A great potential hire might not happen to know much about VB forms; a "no-hire" might by happenstance have recently tried to create a .java file with multiple public classes in it. When I talk to people about interview questions, I always encourage them to pick questions that give the candidate an opportunity to think, not just spit out facts. For example, most of the sample questions on that page could be improved by giving the candidate the answer and then asking them to talk about why they think it works that way. And requiring thinking on their feet is one reason that coding questions work well; it's not whether they write great code, it's whether they think about it first, how they decide if it is correct, how they discuss possible improvements...that's what you need a good interview question to show you. ]]> http://www.proudlyserving.com/archives/2008/02/dubious_intervi.html http://www.proudlyserving.com/archives/2008/02/dubious_intervi.html Wed, 13 Feb 2008 21:45:06 -0800

In a normal year the candidates are decided by "Super Tuesday", and by the time the Washington caucuses roll around, one candidate has established an unbeatable lead and it's all over but the shouting. But this year, with Obama and Clinton neck and neck, Washington suddenly became important (I'm talking about the Democrats here; as readers of this blog may know, I'm an inveterate liberal). Both candidates visited the state yesterday, and we received many phone calls (some automated, but most not) from people urging us to attend our local caucus. My wife spent some time talking to a 74-year-old Obama supporter from California.

For state constitutional reasons, Washington has a primary in ten days, but the Democratic party chooses its delegates via caucuses and then ignores the primary results. It starts out at the precinct level, then they elect delegates to a county caucus, then that rolls up to a state caucus, and there they choose the delegates to the national convention. I was actually unaware of this until recently, but people did a good job of getting the word out that the important votes were happening today at 1 pm.

About ten precincts were caucusing at our appointed site, which was the school district building (the place was a zoo; see photo). My precinct, which I recall from letter-writing campaigns for Laura Ruderman has about 200-300 houses, had 58 people show up, which I think is an impressive number (evidently the turnout was more than double that of four years ago). We had already indicated our preliminary votes and the tally was 36 for Obama, 21 for Clinton, and 1 undecided. Each camp (included the undecideds) could pick one person to give a one-minute speech, in the hopes of swaying the other side. Then they asked if anybody wanted to change their vote (nobody did). Our precinct is allocated 5 delegates to the county caucus (which is in April), and because of the votes the Obama camp got to pick 3 delegates and the Clinton camp got to pick 2. The undecideds would have been able to pick an undecided delegate if there had been enough of them.

In the days leading up to the caucus I had been having an internal debate about who to vote for. I think that both Obama and Clinton would make fine presidents (so for once, I have sympathy for undecided voters); my overriding concern is getting a Democrat elected so that they will form a Democratic administration. Many people seemed to have the same opinion, although there were some people who were basing their decision on their perceived qualities as president (summary of the anti sound bites: Obama is inexperienced, Clinton is compromised by special interests). I think Clinton has higher positives but also higher negatives, and in the general election the positives don't matter much, it's a question of what the Republicans can do with the negatives. I also am slightly annoyed with Bill Clinton's behavior vis-a-vis Obama, which is veering into win-at-all-costs (as it did when he was president; if he had just taken his lumps and allowed himself to be impeached, Al Gore would be president right now). And, fairly or not, I do view a Clinton presidency as "8 more years of Bill and Hillary", and that is also how the Republicans would spin it.

Anyway, I was one of the 36 for Obama, so we gathered to vote on our 3 delegates. There were 6 people who wanted to do it: 3 high school seniors, and 3 adults. They all gave little speeches about why they wanted to be a delegate, and then we voted. In the end the 3 high school kids got chosen. So the delegates from precinct 2448 are Griffin, Marcus, and Kate. Marcus had essentially the same attitude as I did, but Griffin and Kate seemed genuinely jazzed by the promise of Obama. I gather many of the high school students had skipped school to go to his rally yesterday, and Kate mentioned that she had shaken his hand (and like all teenage girls these days, and my daughter, ended her speech by saying, "and so, um, yeah").

There was something really neat about being there at the start of the process that would eventually lead to choosing a candidate. And the down-homey feel of the local caucus reminded me of what I picture a New England town hall meeting being like. I hope our delegates have fun at the county caucus; I suspect that at the next level the knives will come out and the delegates chosen will be the cynical, hard-bitten types, but for today youth and optimism won out.]]> http://www.proudlyserving.com/archives/2008/02/peoples_of_the.html http://www.proudlyserving.com/archives/2008/02/peoples_of_the.html Sat, 09 Feb 2008 22:30:08 -0800 If you've been following the news recently, you may have heard about Kevin Hart, the Nevada high school senior who held a press conference to announce he had accepted a football scholarship from Cal--only to have it revealed that he had no scholarship, and in fact had not been recruited by any of the schools he claimed were in pursuit.

I figured the local papers must be all over this story, and sure enough they are. The Reno Gazette-Journal has a series of articles on the story. The most recent is the "I made it up" one, and from there you can see them all, from the initial coverage of the press conference, to doubts beginning to surface, the mystery deepending, rumors of a shadowy middleman being involved, and then the denouement.

The most poignant, or strange, article is the very first one, the initial press conference. This is covered as a straight "Cool things happening in Nevada story". It starts out "As recently as three weeks ago, Fernley offensive lineman Kevin Hart was all set to commit to Oregon. But on Friday, during an assembly in front of the entire school, Hart chose California over the Pac-10 rival Ducks." (while he was pretending that one school was recruiting him, why not raise the stakes by pretending that multiple ones were and he had pulled a late switch-eroo?). Hart put an Oregon hat and a Cal hat in front of him, then chose the Cal hat (a moment captured in the picture above from the RGJ website--what precisely is going on inside his head at that instant?). Hart, described as "the first Fernley athlete to receive a full scholarship to a Division I school directly out of high school", is quoted as saying "I'm sure it won't hit me until I hit the practice field and get welcomed to the Pac-10"...and then the team coach says, "This is a great day for Fernley High School...This is one young man who is going to represent us on the national level. But we'll always remember he came from Fernley." It's all too horrible/awesome to believe.

The most thorough coverage of the story that I've found is this article at bearterritory.net, a site that covers Cal recruiting and was evidently the first to suspect that something was amiss. The sad part is that Hart really was ranked at a 5.2 by rivals.com, which puts him right in the middle of the 5.0-5.4 band described as "Division I prospect; considered a mid-major prospect; deemed to have limited pro potential but definite Division I prospect; may be more of a role player." So even if he didn't make a D-1 school, he probably could have played in Montana or something. But now it's doubtful any college coach anywhere would take a chance on him.]]> http://www.proudlyserving.com/archives/2008/02/the_kevin_hart.html http://www.proudlyserving.com/archives/2008/02/the_kevin_hart.html Wed, 06 Feb 2008 21:52:44 -0800