Between the opensolaris.org site migration, a code review
for Darren Moffat
, and catching a cold, I'm still having to write my
OSCON 2009 trip
report in dribs and drabs.
The next "people" talk on my list was a talk
by Rolf Skyberg of eBay called "There Are No Unicorns: And Other
Lessons Learned While Running an Innovation Team". Having
worked in a few research settings, but not being a researcher
myself, I was hoping the talk would give me a better
understanding of how innovation happens. And Rolf did have some
things to say here. In particular, he pointed out that
innovation is by nature disruptive, which can lead to
resistance. So be sure to focus on the cultural changes that
will be needed for your innovation to be successful, don't just
focus on the technology or specific product.
The bulk of the talk seemed more about navigating
corporate politics. Rolf's points included the importance of
knowing how your work and your team's work will be evaluated,
and how your project fits into the larger organizational
picture. Understanding how your project fits in is particularly
important when times are tough. If your project isn't in a core
area for your organization, and it doesn't have someone high-up to
defend it, it's more likely to get cancelled
when funding runs low.
Rolf also talked about how traumatic events in a company's
history can affect its behavior for a long time. In
1998 eBay was off-line for 3 days, which led to a very strong
emphasis in the company on reliability and scalability. But,
Rolf argued, the outage also led to an inflexible organization that
has a hard time incorporating new innovations.
I've seen this never-again effect
in other contexts. When I was working
for Xerox, I wanted to look at the source code for Pilot,
which was the operating system we were using. I was told I
couldn't do that, so I asked why. I was told that sometime in
the past, some application code had been written that depended
on an interface that was private to Pilot. I doubt that this
was accidental usage, because all this stuff was written in Mesa,
which made it easy to keep public interfaces separate from
private ones. Anyway, in the normal course of development, the
Pilot group made some incompatible changes to that interface,
which broke the application--right before the application was
about to ship. The Pilot group wanted the application
programmers to fix their code, even if it meant a schedule slip.
But they were overruled by management and forced to revert the
interface change. They vowed that they would not let this
happen again, and from then on they kept their source squirreled
away on private servers, accessible only to people in the group.
I've also seen this effect at Sun. I started at
Sun in 1992,
not too long after Solaris 2.0 had
2.0 introduced a lot of changes that were incompatible with
SunOS 4.x. This caused
considerable disruption for customers, and I gather that many
were not shy in voicing their displeasure. I remember being
told that all the pain around Solaris 2.0 was a big factor in the
decision not to do any more major (.0) releases of Solaris.
Of course, that policy has born considerable fruit over the
years. The ISVs that I've spoken with have praised Solaris
because new Solaris releases rarely broke their code. Other
platforms that their code ran on tended to cause breakage pretty
On the other hand, this compatibility doesn't come for free.
Project teams must design new interfaces carefully, so that they
can evolve in a compatible fashion. The interface review and
cross-checking that is done by the ARCs is
largely manual. Standard (cross-platform) interfaces are not
always stable, so project teams must sometimes do extra
engineering to support the new interface without breaking code
that depended on the old interface. There is a mechanism
for removing old, obsolete code, but again, this requires
supporting the old and new interfaces for some time.
Rolf compared companies to creatures when he talked about
the effect of traumatic events. That seems to imply some
sort of organizational memory of the traumas. But I wonder if
that's really how it works. Is it really an organizational
memory, or is it more the memory of a few key individuals? If
it's the memory of key individuals, then I think
it's not until these individuals move on (or relax around the
trauma) that the never-again imperative starts to lose its hold.
is removing 92,000 lines of closed-source code--the obsolete
smartcard support--from ON.