I have a new theory. It's not about why there are no toilets on the Enterprise
(hint: transporters). This one's about why bad software exists.
Fact #1: the two biggest causes of software failure are requirements failure and integration failure: either the wrong thing is built, or the pieces don't work together when they're assembled.
Fact #2: the only way to get and check requirements, and to make sure that the Fred and Jane's code will play nicely together, is in live discussion. (I'm sorry, but email just doesn't cut it.) That means (drum roll) have meetings.
Fact #3: most people are really bad at meetings --- they don't have an agenda going in, they don't take minutes, they waffle on or wander off into irrelevancies, they repeat what others have said or recite banalities simply so that they'll have said something, they hold side conversations (which pretty much guarantees that the meeting will be a waste of time), and so on.
Conclusion: people create bad software because they're bad at meetings.
Corollary: improve people's meeting skills, and you'll improve the software they produce.
So, here are Greg's Rules for Good Meetings:
- Start with an agenda. If there's no agenda, cancel the meeting.
- Someone takes minutes, so that:
- everyone knows what everyone else thinks they promised to do;
- everyone can be held accountable later (no more "You promised!" "No I didn't!" games);
- people who weren't at the meeting can keep track of what's going on.
- No side conversations. And no open laptops, Blackberries, or anything else that would allow anyone to pay attention to anything except the meeting. (Trust me: if you enforce this rule, your meetings will be much shorter.)
- Exactly one person is in charge, where "in charge" means keeping the meeting moving, glaring at people who are disobeying the "No side conversations" rule, and telling people who are talking too much that they're talking too much.
- No one else is allowed to interrupt. Raise a finger (no, not that one), or make one of the other subtly noticeable gestures people make at high-priced auctions instead. If the speaker doesn't notice you, the person in charge ought to.
And that's it. Run all your meetings like this for a month, with the goal of making each of them one minute shorter than the preceding one, and I promise that you'll build better software.