
FizzBuzz Enterprise Edition - hglaser
https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition
======
userbinator
The sad part is that many Java programmers would probably not realise that
this is supposed to be a parody, because there are even more ridiculous-
looking things in real, "production" Java code:

[http://ws.apache.org/xmlrpc/apidocs/org/apache/xmlrpc/server...](http://ws.apache.org/xmlrpc/apidocs/org/apache/xmlrpc/server/RequestProcessorFactoryFactory.html)

[http://docs.spring.io/spring-
framework/docs/2.5.x/api/org/sp...](http://docs.spring.io/spring-
framework/docs/2.5.x/api/org/springframework/aop/framework/AbstractSingletonProxyFactoryBean.html)
(this one is somewhat famous - maybe it wins the "most number of design
patterns in a class name" award?)

The impression I get whenever I come across code like this is that its authors
were more interested in "creating architecture" than solving a real problem -
and creating many classes containing short methods whose only function is to
create more objects or pass existing ones around is a particularly insidious
form of busy-work.

GNU Hello
([http://www.gnu.org/software/hello/](http://www.gnu.org/software/hello/) ) is
basically the same sort of thing done to a Hello World program.

~~~
ahmacleod
"Convenient proxy factory bean superclass for proxy factory beans that create
only singletons."

~~~
HCIdivision17
I have the urge to find out if a well (or badly?) tuned Markov chain can
generate functional enterprise java code; I know exactly enough java to be
sure all those words in that order actually mean something, but not nearly
enough to have any notion what, precisely, that is.

~~~
ak4g
For those who haven't seen it:

[http://www.classnamer.com/](http://www.classnamer.com/)

The Spring-flavored generator has an extra DesignPatternFactoryMixin.

[http://www.classnamer.com/index.html?generator=spring](http://www.classnamer.com/index.html?generator=spring)

------
SmileyKeith
This was a lot funnier before GitHub introduced the current folder mechanics.
Since you previously had to dig into each level.

~~~
DAddYE
And is not even the longest one seen so far in java land

    
    
        /src/main/java/com/seriouscompany/business/java/fizzbuzz/packagenamingpackage

------
syncsynchalt
They rejected my pull request to migrate their markdown docs to docbook.

[https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...](https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition/pull/125)

~~~
jarcane
_While we appreciate the careful crafting that went into this pull request and
regard XML as an excellent choice for documenting projects of Enterprise
caliber, we feel that moving to Docbook version 5 is a rather hasty move. The
version is brand new, and we are unable to convince stakeholders about its
Enterprise-grade integrity and long-term prospects as a documentation
platform._

Brilliant.

------
ahmacleod
I was trained in Java, but I never had to do any Big Enterprise Java coding.
Can anyone summarize why and when this style of development began?

~~~
patio11
A combination of wasteful architecture astronomy and legitimate need to divvy
up absolutely mammoth line-of-business applications among teams with hundreds
of members operating for years with _wildly_ varying skill levels, often on
different subsystems from different physical locations, with billions of
dollars on the line. You can't let the least senior programmer in the
Melbourne office bring down the bank if he screws up with something, so
instead you make it virtually impossible for him to touch anything than the
single DAO which he is assigned to, and you can conclusively prove that
changing that only affects the operation of the one report for the admin
screen of a tier 3 analyst in the risk management group for trans-Pacific
shipping insurance policies sold to US customers.

The tradeoff is, historically, that you're going to have to hire a team of
seven developers, three business analysts, and a project manager to do what
is, honestly speaking, two decent engineers worth of work if they were working
in e.g. Rails. This is a worthwhile tradeoff for many enterprises, as they
care about risk much, much, much more than the salary bill.

(I spent several years in the Big Freaking Enterprise Java Web Applications
salt mines. These days I generally work in Rails, and _vastly_ prefer it for
aesthetic and productivity reasons, but I'm at least intellectually capable of
appreciating the advantages that the Java stack is sold as bringing to users.
You can certainly ship enterprise apps in Rails, too, but "the enterprise" has
a process which works for shipping Java apps and applying the same development
methodology to e.g. a Rails app would result in a highly effective gatling gun
for shooting oneself in the foot.)

~~~
fsloth
I never understood what the 'risk' in architecture designs meant until your
comment made me realize it is indeed meant for teams where you really cannot
trust all team members ( _shudders_ ). Thanks, I see now more clearly.

~~~
chii
if the decision makers were truly smart, they would've asked to use a provable
programming language like Coq, or at least haskell or something like that (i
hear Ada is very popular in millitary software because of it's contract based
programming).

~~~
mackwic
Not true. It's very difficult to unlock a big budget when you have a small
team. And with Coq or Haskell, you team won't be very big...

Also, ADA is _a bit_ popular, but not too much. Most of the code is still done
in C because of the conformism. Object oriented programming is still
considered like a dangerously modern move. The rules here are pretty hard and
it's easier to fuck up the regulation than the code... ( _cough_ A330 Neo
_cough_ )

------
peeters
The sad part is that there is actually an advantage to abstracting out the
printing of fizz and buzz, and that is it will be easier to test. But the
authors didn't even swap in a testable printing strategy, they just changed
System.out.

~~~
coldtea
Some things it's better NOT to test, rather than create an overengineered mess
to facilitate testing.

Sometimes a fuzzbuzz is just a fuzzbuzz. A.k.a: KISS, YAGNI, etc...

------
imron
I love that there is a commit to 'remove redundant import'.
[https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...](https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition/commit/3732e43bc59070e5f1c9e826d07b6313453d42cd)

Being enterprise software, the last thing they need in the codebase is
clutter.

~~~
syncsynchalt
Well, someone probably had a stretch goal to clean up some of the static
analysis warnings.

------
jdludlow
[https://news.ycombinator.com/item?id=5395215](https://news.ycombinator.com/item?id=5395215)

[https://news.ycombinator.com/item?id=8046186](https://news.ycombinator.com/item?id=8046186)

[https://news.ycombinator.com/item?id=6712425](https://news.ycombinator.com/item?id=6712425)

~~~
archgoon
Yes, but since then, there has been a continual stream of updates, unit tests
(shockingly, the original version had ZERO unit tests), expanded support for a
variety of IDEs, and better code structure.

Also, they author finally got around to actually providing a proper pom.xml
file.

Check the commit history for details.

If you're interested in contributing, there's definitely room for expanding
the unit test coverage, and also instrumenting the build process to support a
code coverage tool such as EMMA or Coberture. Also, I don't believe that the
code has undergone a security audit, and I don't see any code reviews for many
of the commits, which is distressing.

And documentation! The code does not support javadoc, and in fact, there are
only two comments in the entirety of the nearly 1500 line code base!

~~~
insin
> And documentation! The code does not support javadoc, and in fact, there are
> only two comments in the entirety of the nearly 1500 line code base!

This is just _so_ non-compliant with Best Practices that it reveals itself too
easily as a parody.

Each class should at least have the default Eclipse comment telling you how to
change the template for a new class file, and most methods should have auto-
generated JavaDoc for the first version of the method which was written years
ago, with nothing filled in.

------
developer1
The main thing I look for with FizzBuzz solutions in general is how many
modulus operators are used. The junior end of the spectrum tends to use four
(% 5 && % 3; % 5; % 3), while intermediate/seasoned developers will either use
three (% 15; % 5; % 3), or two (storing % 5 and % 3 in variables, then
comparing the combinations).

My personal preference in terms of demonstrating maintainable code is using
two modulus operations with variables. However, I fully understand the
argument that an additional % 15 is preferable compared to the overhead of
storing two variables on each iteration. Both are valid approaches IMO, and
the debate can roar on for eternity. Micro-optimizations and whatnot.

I just don't like to see four modulus operations, which IMO shows a lack of
basic willingness or ability to refactor while coding. It's fine to initially
write the four modulus operations, but if someone doesn't immediately catch
the duplication and do something about it, it screams "I write code until it
works and then move on without cleaning anything up."

Strangely enough, only once have I seen someone use the % 15 optimization
_and_ add a short comment along the lines of "// least common multiple,
divisible by both 3 and 5". Spotting the optimization is nice; placing a short
comment explaining why % 15 when the test is about % 5 and % 3 is a nice
touch. Explains something that might not be immediately obvious to the next
person coming to the code.

Aside: it astounds me how many people, when asked to write a short snippet of
code during an interview, have basic formatting problems and inconsistent code
style. I've seen two lines of code inside an if() block indented at different
levels, with no excuse for "different opinions on formatting". Not a wrapped
line continued on the next, but just two simple statements inexcusably
indented at say 8 and 12 spaces. Don't call us, we'll call you...

~~~
userbinator
How many _zero_ -modulus solutions (and still using a loop, not just a long
precomputed string) have you seen? In my experience, this is the rarest type.
Of those who can write a correct FizzBuzz (which is already a pretty small
fraction of the total candidates), I like to ask "how would you do this
without any modulus" and very few of them can easily see the pattern that
makes this possible.

 _Aside: it astounds me how many people, when asked to write a short snippet
of code during an interview, have basic formatting problems and inconsistent
code style._

If this is being done on paper or an absolutely "non-IDE" text editor then
it's probably someone dependent on an IDE to do the right formatting for them.
If they still do this in an auto-formatting IDE, it's probably a sign that
they have no good idea of the structure/flow of the code.

~~~
detaro
What is the "optimal" answer you are looking for if you ask to solve it
without modulus? Build modulus by hand, or using additional resetting counter
variables?

~~~
userbinator
Two counters, one that counts by 3 and one that counts by 5.

------
adambatkin
This makes me hurt inside.

------
jonah
"Enterprise-strength" stack trace:
[https://plus.google.com/+JeanBaptisteQueru/posts/9oHHUMpwYhG](https://plus.google.com/+JeanBaptisteQueru/posts/9oHHUMpwYhG)

------
GilbertErik
I don't get why all you kids love these obfuscation competitions. ;-)

------
101914
"... necessary tools such as if-/else-statements and loops"

[https://en.wikipedia.org/wiki/Array_programming](https://en.wikipedia.org/wiki/Array_programming)

------
foobarian
Enterprise programming is like Hadoop. Huge startup overhead, but once workers
start up, progress shoots up at a pace faster than possible with less thought
out systems.

------
WasSlowbanned
Verbose way to express that a lot of enterprise Java code is verbose. I wish I
had as much free time.

------
eklavya
ahahahahahahahahaha nice :D

