Screaming Penguin

Steve Yegge has written what I think is a great article on various aspects of Agile development, and what the "good" and "bad" parts are. Really, read it, its the rare informative technical article that is also entertaining.

So the consultants, now having lost their primary customer, were at a bar one day, and one of them (named L. Ron Hubbard) said: "This nickel-a-line-of-code gig is lame. You know where the real money is at? You start your own religion." And that's how both Extreme Programming and Scientology were born.

In my everday developer life I encounter some of the good and some of the bad. One of the most refreshing things about my current job is that most of the managers, at least the ones I encounter, are the Google flavor - that is they know how to code and still do it a percentage of the time. This helps tremendously in my experience. And I mean not just tech leads but actual managers who help guide the overall devisions of the IT department as a whole, and the business. When these people understand technology (I mean understand, not that they just read CIO magazine on the plane) - it helps on all levels and heads off many frustrations further down the chain. This however is about the only similarity, albeit a good one, that my shop has with the Google Way: 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.