CodeSOD: A/F Testing

A/B testing is a strange beast, to me. I understand the motivations, but to me, it smacks of "I don't know what the requirements should be, so I'll just randomly show users different versions of my software until something 'sticks'". Still, it's a standard practice in modern UI design.

What isn't standard is this little blob of code sent to us anonymously. It was found in a bit of code responsible for A/B testing.

 var getModalGreen = function() { d = Math.random() * 100; if ((d -= 99.5) < 0) return 1; return 2; };

You might suspect that this code controls the color of a modal dialog on the page. You'd be wrong. It controls which state of the A/B test this run should use, which has nothing to do with the color green or modal dialogs. Perhaps it started that way, but it isn't used that way. Documentation in code can quickly become outdated as the code changes, and this apparently extends to self documenting code.

The key logic of this is that 0.5% of the time, we want to go down the 2 path. You or I might do a check like Math.random() < 0.005. Perhaps, for "clarity" we might multiply the values by 100, maybe. What we wouldn't do is subtract 99.5. What we definitely wouldn't do is subtract using the assignment operator.

You'll note that d isn't declared with a var or let keyword. JavaScript doesn't particularly care, but it does mean that if the containing scope declared a d variable, this would be touching that variable.

In fact, there did just so happen to be a global variable d, and many functions dropped values there, for no reason.

This A/B test gets a solid D-.

[Advertisement] Forget logs. Next time you're struggling to replicate error, crash and performance issues in your apps - Think Raygun! Installs in minutes. Learn more.