Best Practices On Google’s Software Development Methodology Revealed

In IT, Tips N Tricks on October 12, 2006 at 1:06 pm

Here are some of the best practices that Google follows with its development effort. It seems like the environment is pretty open, reaching out and motivating.

Take a glimpse at the Google culture below.

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.
Google drives behavior through incentives. Engineers working on important projects are, on average, rewarded more than those on less-important projects. The rewards and incentives are too numerous to talk about here, but the financial incentives range from gift certificates and massage coupons up through giant bonuses and stock grants.
Google is a peer-review oriented culture, and earning the respect of your peers means a lot there. More than it does at other places, I think. [..] your actual performance review is almost entirely based on your peer reviews, so it has an indirect financial impact on you.
Google has a long all-hands in which they show every single project that launched to everyone, and put up the names and faces of the teams (always small) who launched each one, and everyone applauds.

Developers can switch team anytime and no questions asked? I still wonder how do they manage that resource gap? If a developer is in the middle of an effort and if he wanted to move out of the team then who is going to fill that gap? How soon? From where? Do they maintain a pool of resources that showed interest to join the team? Or is it like the dev has to wait till he comes to a point where they can replace one person with another? How does that happen real time? I’m just curious.

But overall its pretty neat and simple (as their products) that keeps things moving forward. I wish I could work there sometimes.