Saturday, November 25, 2006

Brief followup to yesterday's post

Whew. I, um, seem to have struck a nerve.

Some things which were implicit in yesterday's post but I should make explicit: I didn't work with any morons; indeed, everyone I worked with was extremely smart. The problems I saw weren't because of any incompetence on the micro scale or even anything attributable to just one person; the slowness and indecision were emergent properties of the system.

Further, as massive as Vista is, it's still just a small piece of Microsoft. One thing which always impressed me about Microsoft was how each team truly did have its own personality and distinct development style. I worked on teams which used Scrum, teams which were small enough to subscribe to no development process at all, and teams which made medium-scale development work very efficiently. I think and hope that my particular nook in Vista was a pathological case which makes for good illustration but whose faults were particularly exaggerated and obvious.

Finally, people have asked what's different at Google. I refer you to my esteemed colleague from the 4th floor for a treatment which is surely better written and more engaging than anything I can say.

1 comments:

ford-prefecture said...

"The problems I saw weren't because of any incompetence on the micro scale or even anything attributable to just one person; the slowness and indecision were emergent properties of the system."

Yes!

Up until I worked at DoubleClick, I had no idea how stuff like this could go so wrong unless everyone involved was incompetant, lazy, or both.

Up until DoubeClick, tho, my largest company was RCN, and the developers there consisted of approximately 5 people (sometimes 4, up to 6) in a small dark room who had complete autonomy.

Before that, it was Panix, and there the developers consisted of: me. Autonomy barely describes it.

I'm guessing that I'm not the only one who's vision is colored by working for smaller types of companies, or at least smaller types of development teams.

Almost without fail, everyone at DoubleClick is extremely bright, compentant, and hard-working. Yet the quality of the code, the consistency of the features, the usability of the UI suffers. The fact that it works at all is a testament to just how good the people I work with are.

Sounds like an oxymoron, non? Yet it's completely true. I've worked with some very bright people (hopefully Panix still means something these days), but DoubleClick is the only place where people are so consistently bright. And hard working. You'd have to be: it's hard to do everything, and figuring out how to get through all the landmines in front of you takes enormous creativity.

I'm not sure exactly where the problem lies. As you say, I think it's more of an emergent property. Lots of things which are only slightly bad with 5 people are marjorly bad with 12 different teams of 5 to 10 people, all inter-related. And compared to MS, I'm sure we've got it easy. If I need something done, I can frequently walk over to a cube or five and get it done without involving a meeting. Sometimes. Although that's less and less possible.

Plus we have people from India doing a whole lot of work for us, so there's an enormous lag when dealing with them. Luckily, they're all really good and clever, too, so things are still possible.

Which is perhaps part of the problem: management overhead's increasing neccessity, coupled with the (at least polynomial, but I suspect factorially) increasing delay overhead.

While the latter may be self-apparent, the former at least is unproven (as far as I've seen). Maybe you don't need so much management, but that certainly seems to be the way things operate. I count myself lucky to have as little as I do.

And let's not place all the blame on managers (although, honestly, it's not even their fault, it's a property of their work). Part of the problem, as well, is entrenched code base. Ours is ten years old, which is fairly old in the scheme of things. Again, it's not MS, but it's older than perl (in any meaningful sense). We have entrenched clients who have their own costs if we decide to break something incompatibly.

Ruby's got it easy. Spolsky has it really easy. Which I wish he'd realize, instead of acting like it's the only possible world that makes sense.