"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).

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.

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)

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".

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

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).

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.

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

undefined

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

Maybe not the guy to listen to anymore.