How A Simple Algorithm Goes Straight To Hell

Several years ago, the Oatmeal did a fabulously hilarious poster that showed how a website redesign starts off on the right foot– only to become completely derailed into a horrible abomination by client feedback and endless revisions.

Web Development is more efficient. We don’t let client feedback mess up our code. Instead, we screw it all up by ourselves.

Ladies and Gentlemen, I present to you the “FizzBuzz Problem.”

Disclosure: I went through a job search in 2014, and no one asked me to solve the FizzBuzz problem in a job interview. The only reason I’ve heard of it is because it was mentioned on Quora. Personally, I think it sounds condescending and alienating, but it makes a great example of “HOW A SIMPLE ALGORITHM GOES STRAIGHT TO HELL!”

Shall we get started?

The objectives in the FizzBuzz Problem are simple:

1) write an algorithm that prints the numbers 1 – 100.

2) whenever you reach a multiple of 3, print “fizz.”

3) whenever you reach a multiple of 5, print “buzz.”

4) if you reach a number that is a multiple of both 3 and 5, you should print both “fizz” and “buzz.”

If you are into the test-driven development/iteration paradigm, your progress might go something like this:

That came pretty close, but for a number that is a multiple of both 3 and 5, it prints fizz and buzz on two adjacent lines instead of a single line. Let’s get them on the same line if we can.

At this point, we’ve met all the criteria and the script should be left alone. Except we both know there’s always a developer out there who has to make a “more elegant solution” . . . right?

Easy is the descent into Hell, for it is paved with good intentions.
– John Milton, Paradise Lost

It usually goes something like this:

Shiny! By using a variable as a flag, we can get rid of those ugly chained if-else statements. See what an elegant programmer I am? #snark

It doesn’t end there, naturally. Someone else comes along and says “Hey, if we make this into a function with parameters, then we can solve this puzzle game using any starting and finishing numbers!” (And I’ll admit it– I’ve been THAT guy before.)

So now we can do things like this:

fizzbuzz(1, 100000);
fizzbuzz(-1000, 1000);

Isn’t that incredibly useful? #moreSnark

But what if we want to play a version of the game that uses different numbers than 3 and 5, or we want to play the game in a foreign language? I know, we can pass even more parameters through the function call!

There! That ought to handle anything we should need.

fizzbuzz(-1000, 1000, 2, 13, “Gallifrey Falls”, “No More”);

Except with all those required parameters, it’s only a matter of time until someone accidentally omits one (which will throw an “undefined” error) or enters them in the wrong sequence (in which case the code will run but likely return unintended results). Yikes!

We can add a verbose documentation header to our function . . .

but no one reads directions any more, do they? #yesEvenMoreSnark

And this is when the Devil himself walks in and says, “Have you considered making it . . . object oriented?”

YES, OF COURSE! WHY DIDN’T I THINK OF THAT BEFORE? EVERYONE KNOWS THAT OBJECTS FIX EVERYTHING! (And we can even initialize our properties with default values that users can override as needed.)

And that, Ladies and Gentlemen, is how to transform a simple for loop into a JavaScript object with more documentation than actual code.