Although I have a hell of a lot of wine at home, for some reason it's the pinot noir that keeps disappearing on me. This is frustrating because it's always more expensive than usual, and it's damn near impossible to find anything good. The $10 Montana/Brancott stuff from Costco was disappointing. The Hill of Content pinot is by far the best I've found at around $12. I wish I had some.
Given the pinot noir comment, I fear I'm turning into my father more and more with every passing year. On the other hand, my Dad is awesome. This is not even remotely a bad thing.
Windows Vista: It took them four years to do a new skin? I installed it at work yesterday and... well... that took FOUR YEARS?!?! Apparently I need to run it on modern hardware to appreciate it [it's on a crappy old PC with abysmal video support]. Ah well.
Robert Wilson's Isamu Noguchi exhibit was fun, but frankly, it's 95% Robert Wilson. That's probably why I liked it.
Watched a lot of old footage from Martha Graham modern dance from the 1940s last night. That stuff looks, well, lame. I kept flashing back to the Mr. Show episode where Bob & David meet their high school counselor who thinks that acting is a ridiculous profession. Later, I realized I should have been flashing back to the landlord from The Big Lebowski performing his dance piece. Modern dance: something I'll probably never appreciate.
Still, there's something special about 1940s/1950s dance. It just looks so... outré. Weird costumes, intentionally arty dance moves all over the place, heinous music by the also-rans of the 20th century. My favorite ones are where they appropriate indigenous peoples' culture to make it even more arty - cf. Corroboree, which is a hoot. You can see some of that at the Aussie national museum.
4 more months and I'll be in Argentina. I need to make with the planning immediately. Must book hotels in Mendoza.
I've never worked anywhere as Byzantine as Microsoft. Over and over again, I find myself astonished at the number of people it takes to accomplish even the smallest task, and the incredible cost of those people [half of them always seem to be contractors, and there's no way they can be cheaper than full time employees, I guess]. It seems like every product or task, no matter how simple, must be broken down into incredibly tiny tasks or components; then, those must be reassigned to other groups inside or outside the company with theoretical subject expert knowledge of the area which invariable proves entirely useless. Instead of a company full of people that are brilliant in very all-round, polymath ways [at Netscape, for example, PT Nunn wrote graphics libraries and produced watercolors at the same time], this is a company full of people that seem to be idiots savants, but waaaay too heavy on the idiot. There's a rampant fear of hiring someone whose skill set is perhaps a superset of what it'll take to get a job done, but of course this is an ongoing disaster; if you hire someone who can only write to write a user's guide [for example], you need to spend months training them on everything else, which of course means that you practically write it for them. If you hire a tester to do performance testing, it seems like they don't know how: they just want you to tell them what to do, so they can do it. It's exasperating. Over and over again I find myself in situations where I could easily do everything required to ship a product and do it under deadline, but that's not the Microsoft way; instead, we split up the work into eight different components, and then kill the schedule by finding temporary contract workers, training them to do it... then they take twice as long to do it as I, if at all, and then we let them go, thereby ensuring the investment we made in training is completely non-reusable.
The development model at Microsoft seems to be hobbled by the idea that all testing must necessarily happen in lockstep with the development cycle. That is, because testing is seen largely as something that you do to the source code [eg you need to add test hooks there], writing code gets stretched out for weeks or months because the developers are really developing two things at once: the application itself [the Ding an sich for you Kantians out there], and then the infrastructure for test automation. This is potentially a good thing; some types of software are better tested using test hooks. However, most of the time, this happens because Microsoft is in the habit of decreeing One Thing Only this year's fashionable, er, excellent methodology, and rigorously applying it across the entire company, regardless of benefit. For example, Mac Office 2004 was, it seems, delayed largely so that they could revamp the entire AppleScript support in the product to provide better test automation support. Now you, dear reader: Does Office 2004 on the Mac seem any better than Office:x? If so, how? Was it worth the extra year's wait? If you had a bunch of AppleScripts you used with Office before, did you mind that they all broke in 2004?
I often wonder if I work for a company that values shipping test automation infrastructure more than actual software. Other days, I wonder if what we're really shipping here are test metrics: what's the code coverage support? what's the percentage of build verification tests that are automated? And at the end of the day, if we're lucky, we accidentally ship real consumer software in between shipping test automation and metrics.
The way we develop products is also fundamentally flawed. It seems to work like this:
- Get a college intern; put them to work for a summer doing something useless, such as being a booth bunny at barbecue for fellow interns
- Then, if they were sufficiently clubby with the rest of the team, hire them full time, regardless of skill set
- Then, have them design your new product. Give bonus points for failing to know anything about the software industry, software development in general, the possibilities and drawbacks of your platform of choice. Fail to make sure that they're doing anything the rest of the world gives a rip about.
- Then, when they've designed the product, make sure that any omissions on their part [of which there will be a multitude] are not allowed to be fixed during development because "it's not in the spec."
- Similarly, whenever they've left something out that's blindingly obvious [for example, what do we do when a MSN Messenger-only user (a so-called EASI - E-mail as sign in - Passport) tries to check Hotmail?], ignore that as well because it wasn't spec'd.
- Finally, when it comes time to ship, and the product sucks, make sure everyone forgets that the PM [product manager] was responsible so that you can send them on to their next assignment.
OK, back to work.