Get your flu shots, kids!

I am just now emerging from a flu haze that first registered last Wednesday with a high fever that persisted through Christmas Day. Even after the fever went away, I was left with a cough and a general sense of fatigue that has been difficult to shake even now. Apparently, I’m not the only one — there appears to be a special California strain of the flu going around this year. In any case, I have a feeling that can only be described as deep disappointment that my visions of relaxation and movie-watching were simply not achieved (though there is still a little time). Instead, I was left in that state of being too feverish to read or even watch TV enjoyably.

On the bright side, if you’re gonna be sick, you might as well be sick when the world around you is moving slowly, because then you don’t get behind. And, I have to say, I had a lot of positive things to reflect upon as I drifted in and out of sleeping off the fever, so I can’t really complain too much. Life has been very kind to me this year, and I am very grateful.

The moral of the story: get your flu shot while you can. Don’t be like me and develop your immunity the hard way!

Merry Christmas

Merry Christmas (or whatever holiday you and your family celebrate!) Here are a couple of festive photos from my Flickr photostream:

Me on Christmas morning in 1975, at 3 years old — 30 years ago tomorrow
Christmas 1975

And my dog Jabari, after a trip to the pet store last week to get dog food resulted in an unanticipated purchase:

Jabari with Santa hat and beard

Happy Holidays!

Mashup Camp: a cool idea

David Berlind is working on a simple but killer concept for an “unconference” he’s calling “Mashup Camp” (and he’s already got the domain, so it’s not just an idle idea):

My goal for Mashup Camp is to do the opposite of what all these other Web 2.0-esque conferences are doing. It won’t be invitation only. The pilot event will be modest in size guaranteeing intimacy and low or perhaps even no cost to attend (perfect for some of the people doing the real innovation on a low budget). And, it will involve a mix of open networking time, leader-facilitated discussions that address some of the most important issues and concerns that the API providers and the mashup artists actually need to work out, and fun (for example, a hottest mashup contest with an even hotter prize).

I think David’s concept nails a clear deficiency in some “Web 2.0” events: beyond all the talk about good ol’ RSS, there’s a deeper story about what’s happening in the broader world of APIs that is often glossed over. RSS is still important, but we need to expand the discussion. APIs are where the action will be in the coming months. The “mashup” theme broadens the discussion in all the right ways without losing sight of the technical guts that make everything work. I think the mashup concept is also something both business people and API providers can get their heads around. It’s a nice hook.

If you want to help David put this together, be sure to read the rest of his post about the idea drop him an e-mail. (Full disclosure: David is a friend from my InfoWorld days, but knowing and talking to David about this just makes me even more enthusiastic about the idea.)

(Technorati tag: )

A coding Christmas

The holidays make me a little reflective, and this year I realized something about my career that really blew my mind — for the first time since 1994, I am not directly responsible for production code or production systems! I can’t recall any particularly ruined holidays in the past (except a vicious DOS attack on July 4th one year), but in my past work, there has always been at least the possibility that a major system would have a problem and I would be responsible for dealing with it (or at least making the dreaded call to the person on my team who would have to deal with it). Right now (though I am super-busy), I don’t even have root on a single system at work. I might be lucky in that regard this year, but I will raise a virtual glass to all the people who keep the systems running during the holidays. . . . you deserve our thanks. Here’s hoping that your pagers and cell phones are silent during this holiday season.

I’ll be using the holiday opportunity to catch up on some non-tech reading, movies, guitar playing, etc., but Im also planning to get some hands-on time with some of the geek stuff I’m been too busy to play with lately, namely: Greasemonkey (using Mark Pilgrim’s Dive Into Greasemonkey), the super-cool new JSON stuff we’re offering at Yahoo!, and some miscellaneous blog tweaks. Yes, “fun” comes in many different forms.

I am not the founder of InfoWorld

There’s an article about what we’re doing at Yahoo! in the UK Guardian today that is worth reading (“Search for a fresher taste“), but there’s one thing factually wrong with this sentence (and also one stylistic tweak):

Through a series of hires and acquisitions, Yahoo is clearly assembling a squad of innovators and forward thinkers. Schachter joins a list of employees including Flickr co-founder Caterina Fake, the founder of technology news service Infoworld, Chad Dickerson, and blogging technology academics such as Danah Boyd and Cameron Marlow.

Though I would claim it with utter pride if it was true, I am not the founder of InfoWorld. Had I founded InfoWorld in 1979, many child labor laws would have been violated, I’m sure (I was seven at the time). InfoWorld’s 25th anniversary issue was published in late 2003. That being said, I am honored to be mentioned at all in the company of people like Caterina, danah (yes, lowercase — that’s the stylistic tweak) and Cameron, both of whom are far more than mere “blogging technology academics.” Nothing like working with brilliant people who are also a lot of fun.

Update: Look in the comments for one from Bobbie at the Guardian — they are going to correct the error. These things happen. I am impressed with the thoughtful follow-up and remain proud of my association with InfoWorld and the work I did there as CTO.

Corporate blogging panel at Syndicate

(Update: links added as the wi-fi improved)

I’m sitting in on the corporate blogging panel at Syndicate moderated by Charlene Li from Forrester, featuring Jeremy Zawodny (fellow Yahoo! and my cubemate), David Geller (WhatCounts), Greg Renaicker (Newsgator), and Jodi Baumann (Network Appliance — where Dave Hitz has a blog). A few random thoughts on the panel (if you’re looking for a blow-by-blow summary of the panel, this is not it):

Early in the panel, someone in the audience asked Jeremy what a “blogroll” was when he used the term. I’m pointing that out not because it’s a bad question, but precisely because it’s a reasonable question for someone who wants to learn about blogging. Luckily, there’s a decent blogging glossary that I just found (though I’m not sure I’ve ever heard terms like “blogroach” before and many of the words are superfluous to someone who wants to understand the basics).

Earlier in the panel, Jodi Baumann said, “we’re a public company” a lot in describing their relatively conservative approach to their corporate blog — of course, so is Yahoo! (granted, we are a consumer-facing company, not a hardware company) I work at Yahoo! (so I’m biased), but I think the way Yahoo! handles “corporate blogging” is a model for any public company — and it hasn’t gotten us in trouble yet that I know of (same goes for Microsoft and Sun, of course). We have a handful of official Yahoo! blogs (Y! Search blog, Y! Developer Network blog), but the corporate blogging policy (PDF) for individuals with their own blogs (which I think is reasonable and necessary for a large public company) allows and encourages blogging within well-conceived guidelines that address appropriate legal issues. Official corporate blogs aside, as the talent wars heat up again in Silicon Valley and elsewhere, I think encouraging employees to express themselves in their personal blogs is a competitive advantage in hiring. In that sense, I think companies thinking about “corporate blogging” should have the courage to extend their policies to address employee blogs explicitly. Yahoo’s blogging policy was a big factor in why I joined the company (and since I joined, my blog has helped me meet people within Yahoo! which has helped me get up-to-speed faster).

There’s also a “just do it” quality to blogs (again, within reason). Charlene Li noted in closing the panel that the first GM blog went from conception to launch in eight days. If GM can do it in eight days (with all the legal issues of a giant public company), it shouldn’t take much longer than that for any company to do it.

Platforms and the rule of three

Back in my old gig, I wrote a feature-length story entitled “Top 20 IT Mistakes” and wrote a followup blog post in which I referenced the excellent Facts and Fallacies of Software Engineering by Robert Glass, writing:

The book contains 55 facts ranging from the people-specific (“Fact 1: The most important factor in software work is the quality of the programmers”) to more specific rules of thumb about the process (“Fact 21: For every 25 percent in problem complexity, there is a 100 percent increase in solution complexity”). There are also 10 fallacies (e.g. “Fallacy 3: Programming can and should be egoless”). Both the facts and the fallacies are organized in a uniquely readable way — each one is a self-contained unit (cross-referencing the others when appropriate) that is divided into “discussion” (an outline of the collected wisdom behind the fact or fallacy), “controversy” (a description of why it is controversial), “sources” (a discussion of the source material available on the subject), and “references” (a traditional bibliography for that particular fact or fallacy).

These days, I’m thinking more about platforms than avoiding IT mistakes, and Glass’ book has helped clarify my thinking once again. Recently, I was thinking about what made a technology a “platform” technology (particularly in the context of the Web 2.0 “web as platform” concept) and I had decided that the platform test was simple: if a piece of technology served two or more separate systems, then it’s a platform, so platform technologies should be designed to do that. With that in mind, I looked into Glass’ book again and this time, Fact 18 suggested that my minimum was one short:

There are two “rules of three” in reuse: (a) It is three times as difficult to build reusable components as single use components, and (b) a reusable component should be tried out in three different applications before it will be sufficiently general to accept into a reuse library.

This sort of language seems very particular to writing code libraries/modules for use inside an organization, but I think the thinking clearly extends to web services that are intended to be “platforms.” Glass goes on to say that the skill set and approach required in building reusable code (and therefore “platform” code in my mind) is unique:

It is no wonder that knowledgeable experts say it takes three times as long. It is also worth pointing out that, although most people are capable of thinking about problems in a generalized way, it still requires a different mindset from simply solving the problem at hand. Many advocate the use of particularly skilled, expert generalizers.

The second rule of thumb is about being sure that your reusable component really is generalized. It is not enough to show that it solves your problems at hand. It must solve some related problems, problems that may not have been so clearly in mind when the component was being developed. Once again, the number of three — try your component out in three settings — is arbitrary. My guess is that it represents a minimum constraint. That is, I would recommend trying your generalized component in at least three different applications before concluding that it truly is generalized.

Those three applications don’t have to be huge, of course, and not all companies even have three products, but the “rule of three” seems reasonable when you’re thinking about building platforms. Maybe you won’t build those three apps to leverage your platform immediately, but you better be thinking about what those three apps might be.