If something is worth doing...

Earlier this year Jeff Atwood over at codinghorror wrote a post entitled Why Can't Programmers...Program? It was an interesting article detailing outlining some serious issues with the Software Development Industry. In the post, Jeff talked about the FizzBuzz problem:

  • Print the numbers from 1 to 100
  • If the number is divisible by 3 print "Fizz" instead
  • If the number is divisible by 5 print "Buzz" instead
  • If the number is divisible 3 and 5 print "FizzBuzz" instead

This problem is supposed to be given to potential employees to determine whether they actually can code (Software Development has to be one of the few industries where this is actually necessary).

It isn't a hard problem at all but hundreds of Coding Horror readers promptly responded with their own implementations in various languages usually with efficiency in mind. It was such a strange response that Jeff wrote a follow up post calling the FizzBuzz problem the "Programmers Stairway to Heaven".

I was amused, and I will admit that I did actually write my own implementation in Ruby. A few months later I was even more amused when I was actually asked to write a program during a job interview. The program was of course "FizzBuzz" but the interviewer had added two minor tweaks. Firstly, there was a requirement that it be written in Visual Basic .NET. I'm a C# guy so this was somewhat difficult. The second requirement was that the program be "testable". You didn't have to test it you just had to be able to explain to the interviewer how you would go about testing it.

I did well enough that I was offered the job and that should have been the end of it. For some reason though I was unable to get FizzBuzz out of my mind.

So it was that as I began to play with some development tools and techniques recently I found that I needed a project. Nothing complex, just a little bit more extensive than Hello World. Thus Enterprise FizzBuzz was born.

This project started as a purposefully naive implementation of FizzBuzz and grew into 3 assemblies, 16 classes and a suite of nearly 50 unit tests. To aid in the process I used a number of tools including:

I would highly recommend all of these tools to anybody doing development in the .NET space and I am trying to organize commercial licenses for CodeRush, Refactor Pro! and TestDriven.NET now.

The code is all available from the Google Code Project site. I recommend using TortoiseSVN to get at it. Or you can just grab the source release as a zip file.

There are two solution files included. One relies on the MbUnit and Rhino.Mocks frameworks to build. The other contains just the application and has no requirements (other than Visual Studio).

I thought that the project would be a useful example for people who aren't sure about unit testing or object mocking frameworks. Also, I think it is a fairly good example of a complicated design. Each class has exactly one responsibility and does it well. All classes cannot be constructed in a non-working state and shouldn't be able to enter a non-working state either. All of the Business Logic for the application is one assembly making it easy to change if the client wants to modify the way the application works.

I want to stress that I don't write this kind of code every day (although I would certainly like to). This was an experiment in just how far you could push the maintainability and reusability of a given piece of code. It is also a work in progress and likely always will be. If you have any questions drop me a comment here on the blog or send me an email at michael-DOT-minutillo-ATNOSPAMPLEASE-gmail-dot-com.

Posted by: Mike Minutillo
Last revised: 27 May, 2011 02:42 PM History

Comments

30 Mar, 2010 04:27 PM @ version 0

Reminds me of GNU hello. GNU hello is an example of "Hello World" as a fully conformant GNU project.

03 Mar, 2009 12:25 PM @ version 0

@Jonas - Well the next step is to add in some kind of container into the application which can be configured from a giant XML file thus getting rid of the hard-coded constants. After that I'd be building a designer for that XML file so that business experts can Fizz their Buzzes without me even getting involved. After all, we have a big bag of re-usable components that are all individually tested. Why not leverage that?

03 Mar, 2009 11:47 AM @ version 0

I think TRWTF is that the fizz and buzz constants (3 and 5) and the bounds (1 and 100) are hardcoded, so your "very elegant" overengineering guards you against everything except changes in the spec :D

13 Aug, 2008 07:06 PM @ version 0

Over engineering aside, this is actually a very elegant design. I'd love to see an interviewers face if you presented this as a solution to FizzBuzz...

21 Sep, 2007 06:04 AM @ version 0

Enterprise FizzBuzz. Love it!

No new comments are allowed on this post.