"Agile sucks! Google rocks! ymmv"

My mind has been chewing on this blog post from Steve Yegge for about a week now. I think I finally figured it out.

It's not that I have a horse in the methodology race (though I'm fond of "agile" for it's "manifesto-like properties" and general non-waterfallness, moreso than any particular feature, per se), but... I'm a sucker for good arguments, and I really hate bad arguments.

The problem I have with Steve's post is that it's making a really bad argument.

I should say, I started reading it one night, just before bed, and had completely written it off (somewhere around "anything called 'methodology' has to be stupid") but, by the next morning, forgot that I was writing it off, and finished it, anyway. I'm glad I did, because it's an interesting article. Really interesting.

The thing is, I just don't think it concludes the way Steve wants it to conclude.

The summary goes like this: "Agile sucks! Google rocks! YMMV." Or, if you prefer: "Agile sucks! Methodologies suck! Consultants suck more! Google rocks! YMMV."

Eh. Okay, be fair: 'Agile' is a deliberately loosely structured attempt at organizing software projects, and attempts to situate itself as the opposite of 'Big Design Up Front', where a project is documented to death before development begins. Steve doesn't like 'Agile' because he's rarely-if-ever seen it well implemented. Then writes about how development is done at Google.

The Google-centric parts of his article are fascinating behind-the-scenes peeks at Google, and it's worth reading his article for that bit, alone.

But.

The problem I have is with Steve's premise: That Google and "most software projects" have all that much in common.

This seems kinda obvious to me, but it seems to need explicating.

The crux is in this detail (which seems to have gone largely unnoticed, so far):

developers can switch teams and/or projects any time they want, no questions asked; just say the word and the movers will show up the next day to put you in your new office with your new team.

That's the clue that Google's team is not like mine. Or yours. Or most anyone else's.

Hang on, let me approach this from the other side for a bit...

The Real Question

The question that I, and people who don't work for Google, are trying to answer, goes something like this:

"How can I deliver this project on time?"

People turn to 'Agile' because it helps them address this question. Actually, I'd say, people turning to 'Agile' are doing so because they're asking a slightly different question:

"Given my existing development team, and the deadlines I have to meet, how can I structure this project to deliver something good?"

(But even this is really just Yet Another permutation on "Good, Cheap, Fast; Pick Two".)

The point is: Google throws out the first two "givens". There are no hard deadlines (apparently), and the team is infinite.

Infinite isn't quite the right word. Google has an unbelievably large budget, and appears willing to use it to acquire talented developers. Still, there's a strong level of diminishing returns with team size; enter flexibility.

The largest project I've worked on probably had a dozen people at any given time, with several teams of 2-5 apiece. Knowledge was specialized enough (not just intra-team, but inter-team) that one just couldn't allow - let alone encourage - random drift between teams. At some point, small number statistics takes over.

But I imagine it works well at Google. They don't have strict deadlines, apparently, so losing a little time to catch the new guys up to speed isn't too detrimental. (And the new guys are probably geniuses, anyway.)

Heck, the company is large enough, and probably heterogenous enough, that a pseudo-random distribution of employees is probably more likely to succeed, anyway.

And if Google doesn't have the talent in-house, they go get it. How many companies have that kind of mercenary attitude toward employment? (How many could afford it?)

Google is Optimized for a Different Problem

So, this company has a giant team of high-IQ geniuses, and they don't give them deadlines. In other words, their problem is nothing like my problem. And it's not the kind of problem 'Agile' is built to solve. Google's problem is more like:

"Given infinite resources, how do we make sure the important problems get solved earlier?"

Oh - and is anybody else disturbed by the "trough" metaphor at Google? I mean, is there more than a passing similarity between their "lazy food distribution mechanism" and "work queue mechanism"?

Permalink • Posted in: blogs, google, rant, work stuff • Comments (1)