Raph Koster - Rigid programming philosophies are the devil

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

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.

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

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

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

Maybe not the guy to listen to anymore.