
Why can't programmers design software? - pcr910303
https://qnoid.com/2011/02/23/Why-cant-programmers-design-software.html#main
======
jiriknesl
Is it just me? I don't like this design.

What's the point of wrapping an algorithm in strategy, when there is no reuse,
nor any need to exchange algorithm?

And more. Why FizzBuzz(15), Buzz(5), Fizz(3); in enum and not in the
constructor?

Why "mod" attribute, when the rest of the code doesn't use shortened words? It
should be modulo.

Why FizzBuzzOperator when FizzBuzzStrategy's initialization is that easy?
Also, again there's no requirement for reusability.

The code here is a classic example of why people make jokes about (usually in
J2EE) overengineering solutions where even FizzBuzz will be designed for
1000MD-average-task-size scale.

I have switched to Clojure for good. Our FizzBuzzes are oneliners
[http://www.learningclojure.com/2014/05/fizz-buzz-
interview-q...](http://www.learningclojure.com/2014/05/fizz-buzz-interview-
question.html)

~~~
epicureanideal
The Clojure FizzBuzzes may be one-liners, but they are multiple statements,
which I'd find easier to read on multiple lines.

~~~
capableweb
Which is exactly what you found when you clicked on the link to the blogpost
in the previous comment. So what is your point?

------
vanusa
Very simple:

Because in the precious few hours they have to devote to "pure learning", when
between jobs -- they're only motivated to hunker down and bone up the only
thing that really matters: the latest tips 'n' tricks for passing all those
fun programming quizzes (and the occasional "culture fit" question or two)
that are the mainstay of the modern interview process.

Designing real, usable, maintainable ... _software_? That's much more
difficult to "test" for.

~~~
dnautics
Is it though? I give an interview question where I present a spec to be
implemented. There's no algorithmic trick, but you do have to know to watch
out for common problems (end of array conditions, etc). Sadly though we hired
someone against my vociferous objection that failed my question in the worst
way - he ditched the spec, attempted a complicated solution, and proudly
asserted that "it works" at the end of the interview, because it passed the
four test cases that I wrote as examples. I couldn't identify the bug by eye
and in fact had to write a property testing framework to identify the bug. On
the plus side, I now have a property testing framework for my interview
question.

~~~
whycombagator
Do you ask the same question each time?

~~~
dnautics
low n. I'm just starting out.

------
krebs_liebhaber
I guess it's because I haven't worked on a really massive project with lots of
other people, but I've never really needed to "design" software. Sure,
sometimes I'll stop for a minute to think about the next thing I'm going to
write and how it slots into the existing parts, but for the most part my
programs grow organically. They start from a small kernel, parts of them grow
and are branched off (B-tree style) into new files and subdirectories, and
soon enough the whole thing is complete, or at least as complete as I need it
to be for the moment.

The best experiences I've had programming are with languages and tooling that
make this organic growth and splitting process as painless as possible (Rust
in particular is really strong in this aspect). Doing such a thing from the
top down (as with Java, where you have to be very thorough with your design
patterns and UML diagrams and whatnot) seems unnecessarily difficult and
restrictive.

~~~
restalis
Designing from top down may help you a bit when you already have a mental
model that you'd wish to convey in written form rather quickly, otherwise
risking to loose sight of it when you get into details. UML helped me write
down ideas (mostly communication flows and other behavior related aspects, not
class diagrams), but I can understand why one may feel restricted when that's
not necessary. Growing organically has its benefits for sure (is more fun, at
least), but I also had more than one case of reconciling
diverging/incompatible parts of a system simply because I went ahead of myself
there with improvements on the go. Wasting time on that under deadlines is
less fun.

------
SamReidHughes
I can't tell whether this is real or a parody.

~~~
sylvainr65
It is parody.

------
Retric
Perhaps the issues is a programmer actually writing that in an interview they
would be given a hard pass from any team I would actually work with.

------
declnz
Surely someone needs to mention FizzBuzzEnterpriseEdition [1], which is
clearly the best resource in this domain? Don't ignore the issues, true gold
in there :)

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

------
traderjane
Summary: 2011 OO FizzBuzz joke...

------
stickfigure
Is this article some sort of joke? Poe's Law seems to be in force here.

~~~
sylvainr65
Cannot be anything but a joke. The problem is simple, the solution requires 10
lines. There is no reason, absolutly none, to create an interface for a such
simple problem.

~~~
loopz
Until this is done in Reactive programming style, this is far from complete.

------
baxrob
Maybe it's that ol' Software Crisis or thar Pleasantness Problem

------
0xdeadbeefbabe
Because the language discourages it? Language, or pretentious Pidgin in this
case, limits thinking.

~~~
postalrat
Is it Java the language or Java developers that people think is a joke?

~~~
0xdeadbeefbabe
Hey, minecraft was done in java. It can't be that bad.

