There are some concepts in coaching that come up over and over, especially when you’re coaching noob teams. The notion of signal to noise ratio (S/N) is one of these.
Signal-to-noise ratio is a way to describe some channel of information into the team (or out of it, or both). For that channel, s/n is an assessment that compares the channel’s signal, i.e. useful information, to its noise, i.e. corrupted or useless information. The bigger the ratio, the better the channel is, and vice versa.
We don’t need any further technicalities: our sense of s/n in human channels is always a matter of judgment and approximation anyway.
Testers Have This Notion
Testers already use this concept all the time, under a different wording: false positives and negatives.
A false positive test is a test that says the program is okay when it isn’t. A false negative test is a test that says the program is broken when it isn’t. Testers regard either of these false tests as anathema, to be repaired or removed from their testing scheme ASAP.
Why do this? Ahhh, because a false positive (or negative) is noise. If they get enough noise in that channel (which is not very much), they will start losing track of tests that are true. Once that happens, the testing system becomes increasingly useless as an indicator of quality.
Developers Have This Notion
Developers know the idea, too. If they don’t think so, just remind them by discussing compiler warnings. Most teams use a warning setting of level 4 out of 5, or something similar. Ask them why they don’t crank it up all the way?
If your team is well-behaved and already keeps warnings at level 5 and fixes all warnings before check-in, then just ask them why they bother: they’ll explain s/n to you.
Some teams ignore all warnings all the time. They have implicitly decided that there’s little or no signal in warnings. (If they’re using meta-template programming in c++, they may well be correct.)
Why Coach This Topic?
What’s important about this idea is that it’s simple, it’s intuitively valid, the team is familiar with it, and most of all, it has a gazillion applications all over the agile process map:
- Compiler warnings, as noted;
- Intermittent test failures, as noted;
- Meetings longer than an hour;
- Evil evil evil boilerplate commenting schemes;
- Every-other-line commenting;
- Reports that show way more data than needed;
- Poor presentation skill;
- Team-member mis-communications;
- Results of some QA efforts;
- Staff meetings;
Everyone of these is likely to be a site where the signal-to-noise concept can help explain the desired improvements.
You don’t even have to be very rough about this stuff, usually.
After a ludicrous staff meeting, ask the boss what parts of it she considered most important. You’ll be surprised at how easy it is for people to tell you the important part of what they heard or said.
Naturally, the important part is just another synonym of signal.