Learning Pittsburgh
Ramin Jahanbegloo used to say "you realize that you are learning something when you are caught off-guard by the most unexpected in your area of study."
So when Steve Moyer poked his head into my office at Panasas to tell me I was fired, I realized that I was learning something. Not something as simple as how to measure, and what to measure, and most importantly of all, why to measure, elements of a complex, multi-operating system, high-performance distributed file system1, but something else. I was shocked by the disapearacnce of an engineer a few weeks earlier, a departure so sudden the man's personal effects were left behind, and left ... for days ... before the HR person got around to scheduling their disapearance as well.
Mine was done in under 10 minutes. I was prepared. No personal effects. Nothing I couldn't carry. No second trip.
In the real world, Cambridge/128/495, Research Triangle, Austin, Roca Baton/Orlando, and the Valley of Heart's Delight, worker disapearences as management simply doesn't fly. Engineers have other options than being the last ones voted off the island. It isn't enough to have the panache of CMU, to have foundation money, some DARPA money, and some Menlo Park money. I've managed. I've hired, and even fired. I still regard that as a failing. I couldn't prevent that employee from engaging in a course of actions that would eventually make him a federal fugitive and place him on the FBI's most wanted list.
I think the same laws of social physics hold in Bangalore and Beijing as well. So I have learned Pittsburgh. It is too small to sustain industry, the parts that work are like AT&T's old computer division, competitive in the monopoly-bounded switch market, uncompetitive in the general purpose market. A place where good ideas like AFS, and scalable high-performance I/O, fail to thrive when set free of institutional affiliations. A place to colonize, from away, on the corpses of the failures -- Spinnaker's (NetApp), FreeMarkets (Ariba), Fore (Marconi), Eizel (Nokia), ... a failure rate over 40% -- the same as Silicon Valley's -- when Fargo ND and Nome AK and Dogpatch, for all 50 states values of Dogpatch, are added in and averaged. It is not a bug a coder can write a fix for, nor is it necessarily a bad thing to leave unfixed. The code works, when executed elsewhere.
I'm the primary original author of the Single Unix Specification. Far too many of my former clients are now just names in museums of computing. Fortunately, I enjoy coding as a calling, and somewhere else a compiler hungers for code. Yesterday we closed the door to a moldy house on Darlington Road in Squirrel Hill and cross the Fort. Pitt bridge for the last time as (temporary) residents, and hooked up Rebecca and bent our course towards Greensboro. Sam and Jonah went to the zoo with their classes to end their school period Tuesday last, so we had lots to talk about on the road.
1 Silent data corruption, client memory exhaustion, order-of-magnitude poorer performance for write/read bandwidth over NFS, two orders of-magnitude poorer performance over CIFS, exploding Linux variation ports, and diverging MTBF curves are process bugs, not product features.
Comments
I'm going to miss knowing that you're here in town. Best wishes for a better corporate culture.
I wish you weren't right that "It is too small to sustain industry, the parts that work are like AT&T's old computer division, competitive in the monopoly-bounded switch market, uncompetitive in the general purpose market."
Posted by: zak822 | May 27, 2006 10:59 AM