Google has developed a lot of cool software. Ever wonder how? I’m not a student of software development methodologies, so much of Steve Yegge’s Good Agile, Bad Agile is of little interest, especially the rants about Agile Programming. Yet his description of “Good Agile” is about how Google develops software. If you are interested in Google you won’t want to miss it.
Here is a long quote from the piece, but it’s a long piece and there is a lot more about how the process works. If you find this interesting, read the whole post.
I’m going to talk a little about Google’s software development process. It’s not the whole picture, of course, but it should suffice for today. I’ve been there for almost a year and a half now, and it took a while, but I think I get it now. Mostly. I’m still learning. But I’ll share what I’ve got so far.
From a high level, Google’s process probably does look like chaos to someone from a more traditional software development company. As a newcomer, some of the things that leap out at you include:
– there are managers, sort of, but most of them code at least half-time, making them more like tech leads.
– 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.
– Google has a philosophy of not ever telling developers what to work on, and they take it pretty seriously.
– developers are strongly encouraged to spend 20% of their time (and I mean their M-F, 8-5 time, not weekends or personal time) working on whatever they want, as long as it’s not their main project.
– there aren’t very many meetings. I’d say an average developer attends perhaps 3 meetings a week, including their 1:1 with their lead.
– it’s quiet. Engineers are quietly focused on their work, as individuals or sometimes in little groups or 2 to 5.
– there aren’t Gantt charts or date-task-owner spreadsheets or any other visible project-management artifacts in evidence, not that I’ve ever seen.
– even during the relatively rare crunch periods, people still go get lunch and dinner, which are (famously) always free and tasty, and they don’t work insane hours unless they want to.
These are generalizations, sure. Old-timers will no doubt have a slightly different view, just as my view of Amazon is slightly biased by having been there in 1998 when it was a pretty crazy place. But I think most Googlers would agree that my generalizations here are pretty accurate.
It’s like grad school, only the pay and the food are way better
Really smart people, work on what you want, few meetings, small teams. What’s not to like? Some of the commenters argue that while it works for Google, it doesn’t work in business, because businesses have competitors and there is pressure to be first, or at least not way last. Which makes some sense to me.
Google is only competitive in the market they dominate
Google dominates the context-sensitive online advertising market using their search technology. They are making very good money from that business. All their other services are also-rans because they don’t have the discipline and incentive to make them successful. So most of the software Google is working on are sandbox projects. There is no urgency because Google has no strategy to promote and monetize them.
So what does this have to do with storage?
Not a whole lot. As I’ve examined Google storage technologies, GFS and Bigtable, I’ve come to believe that while the design principles are worth emulating, the actual products aren’t useful in the enterprise because they lack necessary features. Similarly, I suspect that Google software development techniques aren’t transferable either. But they are certainly drool worthy, and pehaps they’ll raise the bar for developers elsewhere.
Its interesting to see how they approach software development. Very developer centric which is good…up to a point.
But I think its way too laid back. In particular, being able to bail from a project at any time must make task scheduling difficult. Certainly, for the projects I’ve worked on that have non-moveable deadlines, working this way would carry the danger of products being delivered with a significant number of features either only partially implemented or just missing all together. Software scheduling is difficult enough already.
Frequently, I have to do tasks which are nothing short of a nightmare to implement (my speciality in fact :). I’m not sure I’d have reached the end if I or another members of the team could have just walked away when the going got tough.
Still, sounds like a cool way to work. Almost like working on a hobby project. Now, if I could get a few billion in the bank account perhaps I could work this way as well 🙂