Whimsical bug reports, while not a common occurence, aren’t exactly unheard of either. They are a popular way to vent a shared frustration and lighten the mood.

Recently, we changed milk suppliers for our cafeterias. Well, more accurately, our previous milk supplier was bought by another milk company. The problem is that the single-serving milk cartons from the new company are hard to open.

So of course what you do is file a bug.

Bug: New milk cartons are hard to open.

Repro: Go to cafeteria, get milk carton, attempt to open it, get napkins and clean up mess.

(The reason is that the milk company bought a brand new machine which seals the cartons with too much glue. They are working to adjust the seal.)

A few work-arounds were suggested, including bringing your own cow and a three-step process of freezing the milk, tearing the carton open, then allowing the milk to thaw. Others explain that the fix is held up in testing: “Currently only 3 testers are handling this component and they can only drink 8 cartons a day. The team could conduct more carton-opening tests but carton-tasting, milkflow testing and carton pressure tests are still remaining.” Plus of course a security review needs to be made of the consequences of a weaker seal.

This is a particularly software-oriented joke, because it highlights how hard it is to make bugfixes in software – by applying the software testing regimen to something that isn’t software. You can’t assume that a simple, local change like adjusting the amount of glue applied to the carton will result in a simple, local change in the final product (a more acceptable seal strength). Software is nonlinear. A simple change can have effects (some catastrophic, some subtle) far, far away from the point of change.