I just read Good Agile, Bad Agile from Stevey's Blog Rants. Don't know much about him, but he was a developer at Amazon way back, and now works at Google. It's a long post, and really hit home on a few particular areas of software development.

Excerpt #1 about how most companies approach software development:

• hire a bunch of engineers, then hire more.
  
• dream up a project.
  
• set a date for when they want it launched.
  
• put some engineers on it.
  
• whip them until they're either dead or it's launched. or both.
  
• throw a cheap-ass pathetic little party, maybe. This step is optional.
  
• then start over.

Ouch. I wish it weren't so easy to cite several great examples of this from my own personal experience.

Favorite excerpt #2 about the laws of marketing:

• anything that calls itself a "Methodology" is stupid, on general principle.
  
• anything that requires "evangelists" and offers seminars, exists soley for the purpose of making money.
  
• anything that never mentions any competition or alternatives is dubiously self-serving.
  
• anything that does diagrams with hand-wavy math is stupid, on general principle.
  

  And by "stupid", I mean it's "incredibly brilliant marketing targeted at stupid people."

I'm starting to really like this guy. This fits nicely with one of my long-held beliefs about products and business: if something is touted as being Really Good but requires a long explanation to prove it, it's safe to assume "Stupid and Bad".

He goes on to talk about specific things Google does to take care of their people - and not just developers, but all of their people. They basically give them everything they need to do their jobs, whatever it is, as well as awesome rewards for doing great work, huge incentives for spending time on things that matter. And "things that matter" does not mean "things that someone gathers metrics about", or "hitting a date".

You cannot put a label or metric on individual little tasks for a developer. Instead, software development is a big moving target that cannot be pinned down. You know when you've hit it (or not), but you cannot tell before-hand what you'll need to do in order to get there. And trying to give incentives based on your provably-incorrect predictions of getting there is a big mistake. You will be wrong, your team will not get "the prize", they'll feel like asses for trusting you, and they'll be a lot less likely to believe you the next time around. Nice. Rinse and repeat a few times, and it won't be long before the team has lost all respect for the leadership. What a way to run a software group.

So given Google's committment to truly taking care of everyone, and going out of their way to address all areas where people could possibly complain about anything, they have created an extremely productive, self-managed group of people who do the right thing without management. People work quickly, projects run smoothly, the results are good, and employees are happy about it.

Excerpt #3, which makes a job at Google sound very attractive:

This eliminates the need for a bunch of standard project management ideas and methods: all the ones concerned with dealing with slackers, calling bluffs on estimates, forcing people to come to consensus on shared design issues, and so on. You don't need "war team meetings," and you don't need status reports. You don't need them because people are already incented to do the right things and to work together well.