Product Design is Everywhere

A friend just posted this oldie-but-goodie article: Why Can’t Programmers.. Program? In it, Jeff Atwood discusses using FizzBuzz as a programming test for developer applicants. He suggested that I could probably crank out some interesting variations on this theme. So I broke out my copy of LiveCode and gave it a go. Here are several solutions:

function fizzbuzz n
    repeat with i = 1 to n
        if i mod 15 is 0 then put "fizz buzz" & cr after R
        else if i mod 3 is 0 then put "fizz" & cr after R
        else if i mod 5 is 0 then put "buzz" & cr after R
        else put i & cr after R
    end repeat
    return R
end fizzbuzz

That’s a fairly straightforward solution that requires just 4 lines of code inside the repeat loop to get the job done. It does check for mod 15 redundantly with 3 and 5.

function fizzbuzz n
    repeat with i = 1 to n
        if i mod 3 is 0 then
            if i mod 5 is 0
            then put "fizz buzz" & cr after R
            else put "fizz" & cr after R
        else if i mod 5 is 0 then put "buzz" & cr after R
        else put i & cr after R
    end repeat
    return R
end fizzbuzz

Another straightforward implementation. it requires 6 lines of code inside the repeat loop, but avoids redundant mod tests.

function fizzbuzz n
    repeat with i = 1 to n
        if i mod 3 is 0 then put "fizz " after R
        if i mod 5 is 0 then put "buzz " after R
        if char -1 of R is space
        then put cr into char -1 of R
        else put i & cr after R
    end repeat
    return R
end fizzbuzz

A third mundane solution. 5 lines and fairly clean, but the test on the last character of the return string is a waste and ugly.

Now, let’s get to the interesting solutions.

function fizzbuzz n
    repeat with i = 1 to n
        put item 1 + i mod 15 of \
          format("fizz buzz,%s,%s,fizz,%s,buzz,fizz,%s,%s,fizz,buzz,%s,fizz,%s,%s",i,i,i,i,i,i,i,i) & cr after R
    end repeat
    return R
end fizzbuzz

Despite the line wraps (the \ wraps are just for display here) that’s a single line with a format function in it inside the repeat loop. The format creates a string of 15 items that match the 15-element repeated loop of outputted items in fizzbuzz, and then uses the index mod 15 to select among them. It has the positive of being a single line, but the line is somewhat complex, especially if the developer doesn’t have a reasonable grasp of the format command, and it’s inefficient because it generates 15 items for each element of the return list.

function fizzbuzz n
    repeat with i = 1 to n
        put (word ((i mod 3) + 3) div 2 \
          to 2 - ((i mod 5) + 4) div 5 of "fizz buzz") \
          & (word 1 to (i mod 3) * (i mod 5) of i) & cr after R
    end repeat
    return R
end fizzbuzz

That’s a single line solution (again, the \ wraps are just for display here) that avoids the use of the format function, which isn’t commonly used in the LiveCode community, at the price of some truly tortured arithmetic and chunk expressions.

function fizzbuzz n
    repeat with i = 1 to n step 15
        put format("%s\n%s\nfizz\n%s\nbuzz\nfizz\n%s\n%s\nfizz\nbuzz\n%s\nfizz\n%s\n%s\nfizz buzz\n",i,i+1,i+3,i+6,i+7,i+10,i+12,i+13) after R
    end repeat
    return line 1 to n of R
end fizzbuzz

This is again a single-line solution with the format function. This one has an advantage over the previous format-based solution in that it generates 15 entries at a time, so it’s much more efficient. It’s probably not any easier to understand, though, and it has the drawback of generating a multiple of 15 lines; it has to truncate the generated solution before returning it in order to return exactly the requested number of lines.

So which of these is best?

This is Product Design/Management enters the picture. Based on brevity or cleverness, one of the last three solutions would be best. Even with appropriate comments/documentation, they would require a developer to spend time understanding them before being able to troubleshoot or modify them. The fifth one, in particular, was fun to write, but would be the subject of many curse words if anyone (including me!) had to modify it in the future.

So pretty clearly one of the first three solutions is best. They will be far easier to understand and maintain in the future. Of those three, I lean toward the first solution. The only drawback it has is the redundant modulo calculation, which is a small price to pay for the much clearer layout of the code itself.

Everything that has a user has an interface with that user. In this case, that interface is the structure and format of the code itself. It’s entirely technical, and it is merely text, but clearly design for usability matters even here.

Always think about your customer! Even if it is your future self.