Friday, March 30, 2012

Fewer Is Sometimes Better

When I'm in a group debugging something or testing something, there's a tendency to start throwing out ideas.

For example, "Hey, guys, I'm noticing that writing to the system is really slow."
"It could be the disk is getting full."
"Maybe there's a network problem - bad cable or bad port."
"Perhaps we're saturating the network link."
"Well, we could just be reaching a really really big index and searching it is slowing down."
"What about memory? Are we swapping?"

We have a lot of ideas, a lot of possibilities, a lot of guesses. Sometimes that's okay. Sometimes you really do need to generate a lot of ideas.

Much of the time, though, we should probably do a little more thinking and a little less brainstorming. Sometimes with additional thought or analysis, we can identify one or two causes that are the most likely, and not end up wasting time chasing scenarios that are implausible as soon as you start to look at them.

Take our example above. Several of the suggestions are network-based. A little thinking could say something like, "well, for each item written, we send X bytes over the network interfaces. At the fast Y rate, that's about 10KB/sec, which is well under the network speed. So at the slow rate we're almost certainly not saturating the network." We can use similar analysis to eliminate index size, disk use or memory as likely candidates based on the total amount of data in the system. All of a sudden, we're down to one or two likely candidates rather than five or six. Our debugging just got a lot more focused.

Brainstorming is good when there are a lot of possibilities about what's wrong, when it's hard to eliminate any possibility, and when there is a large team that can analyze independently. In other cases, brainstorming might not be effective. When the team is small, time is tight, or you're in an interview, take those few extra minutes to think about each idea. Fewer is sometimes better.

No comments:

Post a Comment