Snagged from Daring Fireball: Adobe edits the development cycle

Probably the most effective thing we did was institute per-engineer bug limits: if any engineer’s bug count passes 20, they have to stop working on features and fix bugs instead. The basic idea is that we keep the bug count low as we go so that we can send out usable versions to alpha testers earlier in the cycle and we don’t have the bugalanch at the end.

The goal is to always have the product in a state where we could say “pencils down. You have x weeks to fix the remaining bugs and ship it”. The milestones are primarily measurement points, with the acceptance metric being quality instead of something like “all features in” or “UI Frozen”.

There are two things I’ve seen or heard of which I believe is a really nice idea, software management wise. This is one of them.

The other is the idea of the weekly team meeting. I know most people hate team meetings–and they can become obnoxious if you have a large team. But I’ve been on projects where we never held meetings–and on one project I couldn’t have picked out half of my teammates in a police lineup if I had a gun pointed at my head.

On the other hand, I think team meetings should be limited to one hour a week. Stand-ups (where everyone is supposed to meet for 15 minutes, like the huddle before a game play in football) strike me as a completely useless exercise that only makes managers feel good that they’re “doing something”, and team meetings that last more than an hour or meet more than once a week are also equally a waste of time.