UPDATE: As an aside, it would probably be more accurate to say the
FizzBuzz question is a Requirement. So where you read the term
Spec, you can replace it with Requirement. Either way, the same
thing applies. The only thing not ambiguous is the code. As they say,
the code is the spec.
One last point, then I’m done with this topic of FizzBuzz and spec
writing. In a recent
I mentioned tongue firmly in cheekthat the FizzBuzz
has certain flaws. Now I admit I’m taking this out of context a bit to
make a point. FizzBuzz is an simple interviewquestion, not a spec,
possbily intended to elicit this type of analysis from the
candidate. Even so, I think there’s a good lesson to learn here.
My point was that all specs are merely rough approximations of the
actual requirement. Specs are ambiguous, but software is not.
Software doesn’t generally deal well with ambiguity. Change a random bit
in memory and all hell breaks loose.
However, some of that was lost due to the extremely nitpicky point I
made about the spec. So here’s another, still nitpicky, but a bit less
Every so called “correct” program written in the comments of Jeff’s
blog had the following
But, doesn’t the following output meet the letter of the spec
(difference in bold)?
My point being, the spec is explicit about replacing numbers divisible
by three with “Fizz”, but it doesn’t say to replace numbers divisible by
Yes, I agree. Developers should not act like total logicians and nitpick
every detail. Human language is inexact, and we have to deal with that
fact of life. Unfortunately, sofware doesn’t have the same resiliency
towards ambiguity. If this output was meant to be fed into another
software system, this ambiguity would cause bad data, software crashes,
who knows what calamity!
You might say I’m splitting hairs here. Of course I am because the
compiler is going to split hairs. The Web Service I’m trying to call
is going to split hairs. The HTML browser is going to try and not split
hairs, but is going to ultimately fail. Software is all about
Instead, we need to move beyond the spec and ask questions before
writing code, during writing code, and after writing code. Do not be
afraid to talk to the customer or customer representative. That’s all I
was trying to say.
Thanks to Rob Conery who was
trying to make this point in my
but it was lost on everybody. ;)