
Raph Koster - Rigid programming philosophies are the devil - cyanbane
https://plus.google.com/u/0/103271590817770839429/posts/JbD3eyRGUgU
======
mokkos
"The right way to do things the first time is the way that gets it working the
fastest so you can see if your solution even makes sense.

The right way to rewrite it once that works is to make it fault-tolerant and
scalable.

The wrong thing to do is build a giant system first, and try to account for
every possibility."

Great quotes. There are exceptions, such as when you're making a libarary,
utilities, or APIs, but in most cases, you ain't gonna need it
(<https://en.wikipedia.org/wiki/You_aint_gonna_need_it>).

------
breckinloggins
tl;dr: YAGNI

I am skeptical that this kind of pathology can ever really be avoided unless
you have enlightened management. A game designed entirely in UML? I'm sure the
smart dudes on the team protested. But I've worked for organizations where the
common-sense approach simply doesn't have any weight, because the "right way"
was decreed from on high (or from the last consultant who dropped by).

If you are a three-man team of highly competent developers and you find
yourself in a mess like this, chances are it's your fault. So shame on you and
remember not to do that next time!

But more likely, you are a talented developer with a cozy job at a
"traditional" company with ego-driven non-technical management that dictates
technical approaches to people who know better. You'll never win that battle.
But the question is, why even try? If you find yourself constantly saying "but
this is so unnecessary!" and are continuously being proved right, it's time to
move on. Scary, but necessary for your sanity.

Creative, technical people just don't thrive in a Dilbert environment.
Survive, maybe. But not thrive.

------
extension
The "tools, not rules" programming meta-methodology:

\- Your own reasoning takes priority over any method or principle.

\- If you can't see how a method is concretely helpful, you shouldn't follow
it. The need for it will soon become apparent, if there is one.

\- No method is universally helpful. There are always cases where it is
detrimental.

\- No principle is justified a priori. That a principle "fits" a particular
situation is not a sufficient reason to invoke it.

(these are really all just different ways of saying the same thing)

------
gruseom
_The right way_

That is the ultimate cliche of programming rigidity, so it's ironic that an
article against rigidity would resort to it.

There is no "the right way". Every time I catch myself or someone I work with
using the phrase, I make a point of changing it to " _a_ right way".

~~~
matwood
While there may often not be a single 'right' way, there are definitely wrong
ways to be avoided.

------
rntz
"Prototype as fast as possible" is itself a rigid programming philosophy.

~~~
kstenerud
"Prototype as fast as possible" is a good rule of thumb. It's not always the
right way, but from a business standpoint you're not wasting time polishing a
potential loser, which means you have more time to devote to other potentials.

------
radicalbyte
I've been working for two months on a system built by hackers. Lots of
hackers. All with their own different ideas.

Guess what?

I'd choose Abstraction Overload over Death By A Thousand Hacks any day.

Actually this system shows signs of a different antipattern - the
"Protoductiontype" - the prototype that some idiot throws into production too
soo, which becomes so vital to the business that it's irreplaceable (and
entropies real fast into an unfixable mess).

~~~
svdad
I second this -- strongly.

I've spent the past four months leading a team of programmers assembled for
the sole purpose of dealing with a productiontype system (written by one of
the early employees in a weekend because one customer wanted to evaluate
something), trying to turn it from a hack into a functional piece of software
while half the business is standing on it.

~~~
kstenerud
The problem is not that the prototype was released to the public; it's that it
was left in prototype form for so long after it had proven its worth to the
company.

~~~
svdad
Well, exactly. It was written in prototype, put in production, and ignored for
a year while usage slowly built up.

------
kin
Especially with games, in the prototyping stage a lot of programmers fall into
the trap of trying to abstract as much as they can out of everything they do.
Though this makes sense in certain situations, it hurts the game prototype by
slowing it down and weighing it down with limitations of the abstractions.

------
jhuni
I have exclusively used Lisp for over a year, and I haven't fell into any
traps.

------
VonGuard
Uhm, Raph? Aren't you closing your second startup in two years? Proust is
done, right?

Maybe not the guy to listen to anymore.

~~~
nvoorhies
He's probably precisely the type of guy you should listen to when it comes to
how things _don't_ work as they should.

