Agile Google?

Other than reading this post about code-sharing and 20% time, I know little about Google’s internal software development practices. Do they have epic gant charts constructed from 40 sheets of A3 and sellotape covering an entire office wall? Do the engineers have to email their project manager every week (or, worse, every day) with half-day granularity time estimates and a progress report detailing their latest achievements? Somehow I don’t think so.

Google appear to follow the release early, release often mantra of agile software development. They release products early with a ‘beta’ tag and reduced functionality, then release updates containing new features at frequent (although not regular) intervals. Gmail is a perfect example of this. Even though Yahoo have also started to roll out the beta of their Gmail-rivalling web mail system, you get the impression that their development is somewhat less agile than Google. More Microsoft than Thoughtworks, more donkey than race horse.

Rather than working in agile utopia, it’s probable that Google operate a much more formal, regimented system which combines aspects of several methodologies. They probably have significant requirements specifications, design documents and their UAT phase will be long and scrutinous (although this would be the case irrespective of development methodology), but the simplicity of their products, their productivity and the way they listen to customer feedback is a clear sign of a belief in the underlying principles of the agile manifesto.

Any Googleites out there want to share their experiences?

Posted by Olly on January 23, 2006 at 1:00 pm in agile, software
Comments Off | Permalink

Spectacular vernacular

It’s fairly well known within software circles that, generally speaking, true agile software development is not so much frowned upon by project managers, but rather wholly dismissed as a software engineering flight of fancy. Quite clearly, pair programming = a 100% waste of resources. Obvious isn’t it? Thus, despite advances in software methodologies, traditional BDUF and the Waterfall Model which have been used (and their problems regularly experienced) since the software stone age, still rule. I think we’re still in the stone age.

Over the last year I’ve noticed that agile terminology is beginning to decorate middle management vernacular, despite agile methodology still not being accepted, or even considered, as a feasible development approach in most software teams. Having exhausted such popular words^[1] as synergy, holistic, strategic and collaborative, middle managers have eagerly embraced unit test, iterative and refactor without having concerned themselves about their actual meaning. I’m sure they mean well, but refactor is commonly used alongside or in place of re-write, iterative is randomly thrown in to conversations whilst unit test is, well, just abused (”the inbound process can now be completed and unit tested”).

This “term-abuse” is actually rather amusing and can save your sanity during a tedious meeting, but I think it’s a software developer’s duty to correct a manager guilty of it, or at least try to correct them, and continue to do so until the penny drops (or until you get ‘promoted’ to project manager).

I know it’s only a matter of time before I’m asked, “how’s your continuous integration coming along?”, but at least I’ll be able to reply with, “it’s achieving remarkable synergy with the strategic holistic approach” without fear of sounding ridiculous.

[1] The most hilarious management-speak I’ve heard lately, said in all seriousness to a room of over thirty people, was the frankly nonsense-embracing, “we want to be holistic about our scalable/repeatable logic”. Reader explanations are encouraged.

Posted by Olly on November 16, 2005 at 10:49 am in agile, holistic, project management
Comments (1) | Permalink