In the world of hardware engineering, the concept of signal-to-noise ratio (S/N ratio) is widely used. If there’s too much noise in comparison to the amount of signal, the device will not work well and customers will not be happy. We should pay attention to the S/N Ratio concept when it comes to software engineering too.

Quoting Wikipedia, “Signal-to-noise ratio is defined as the power ratio between a signal (meaningful information) and the background noise (unwanted signal).” For example, radio signals contain interference — miscellaneous radio waves that disrupt the primary beacon. The same is true of optical signals — pictures contain noise that reduces their quality.

Software projects also contain signal and noise. Signal consists of information and activities that are valuable, useful, relevant, timely and accurate. Noise consists of everything else.

S/N Ratios should be as large as possible — signal should always be much larger than noise. Here are a few examples.

  1. Meeting Example: A meeting begins 10 minutes late. 15 minutes are spent reading minutes from the last meeting and summarizing issues. 30 minutes are spent discussing and solving problems. 5 minutes are spent wrapping-up. S/N Ratio = 1 [30 / (10+15+5)]. Better approach: Start on time, eliminate the reading of minutes. Spend 55 minutes problem solving and 5 minutes wrapping-up. S/N Ratio = 11 [55 / 5].
  2. Documentation Example: A requirements document is 100 pages long. The first 10 pages and the last 6 pages are boilerplate. In between, there are 7 sections averaging 12 pages each and the first and last page of every section are boilerplate. The last section is all boilerplate. S/N Ratio = 2 [67 / (10+6+12+5)] Better approach: Eliminate the boilerplate (except for the cover page and table of contents) with a single page reference to standard content. S/N Ratio = 22 [67 / 3].
  3. Testing Example: A project has not automated the regression tests. As a result, the manual tests consume about 20 person-hours per cycle. If the tests were automated, they would consume about 1 person-hour. It would take about 40 person-hours to automate the tests. Over 10 iteration cycles, 200 person-hours are spent doing manual regression testing. If the tests are automated, 10 person-hours would be spent. S/N Ratio of manual testing = 0.26 [(40+10) / 190]. S/N Ratio of automated testing = 999 [(40+10) / 0] (It’s actually infinite but let’s cap it at 999.)

Experiment with this concept a bit and calculate your team’s S/N Ratio. Any number less than one is terrible. At a minimum, aim for five — five times as much valuable work as not-so-valuable (this aligns with the often-quoted, 80-20 rule).