Here is a “Joel on Software” analysis of the MS Vista menu .. and its, hum how to not say something rude, surprising number of available user choices .
The real fun comes just after, when Moishe Lettvin, that was in charge of the developpement of this feature
gives its explanations!…Lenifiant, and “ubuesque”,
…24 people involved in this feature. Also each team of 8 was separated by 6 layers of management from the leads, so let’s add them in too, giving us 24 + (6 * 3) + 1 (the shared manager) 43 total people with a voice in this feature. Twenty-four of them were connected sorta closely to the code, and of those twenty four there were exactly zero with final say in how the feature worked. Somewhere in those other 17 was somebody who did have final say but who that was I have no idea since when I left the team — after a year — there was still no decision about exactly how this feature would work.
Really really something to go through…cause it seems that all kind of organizations may tend to those limits. And it is a good list of what NOT to do, or try to not do when your business is growing bigger….
But things can be different, look a little at Google:
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.
How could this ever work?
And read the whole article also cause it is a refreshing rant about Agile … and a good insight at Google success…and why everyone wants to work there!