Originally wrote “Why Can’t Programmers.. Design Software?” on forrst. It spur a discussion that made some people think about software design; that was the goal.

Wow. Well, that is certainly the most enterprisey Java approach to the problem I’ve ever seen. It seems a bit excessive. Aiming for abstraction at the cost of readability.

Overengineering is how I’d call this. Though the specific use-case is an obvious abuse, the general idea behind isn’t that bad…

I think that this is a fantastic approach. Could someone call this excessive or overengineering? Of course, in the context of FizzBuzz. However, not in the context of software design in general. Far to often we (and I’m more than guilty of this) jam tons of lines of procedural code inside of our classes without thinking of reuse or any sort of abstraction. The point of this post (as far as I can tell, correct me if I’m wrong, @qnoid) is to actually think about what you’re doing, not just blindly build a solution as fast and in as few lines as possible.

Lately have been noticing a lot of traffic coming from @Something_Awful. Felt like writing a follow up because as time goes by, even more developers will come across the post and totally miss the point.

• Q: Should you write an implementation of fizzbuzz in this way?
• A: No.
• Q: Should you shoehorn OO arbitrarily to a software design?
• A: No.

Personally, like to draw the design early. It helps guide developers and show intent.
Is there a risk of over engineering? Absolutely. Even though grammar does help with OO there are concepts that give little room for doubt when it comes to designing software in OO (i.e. object lifecycles). At the end of the day it comes down to experience.

Here is another fizzbuzz implementation that really adds something new to the table.
Not a clue what “deterministic finite automata” is, but it sounds cool.