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.
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'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).
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.
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.
"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.
I think you're confusing me with someone else, or have misheard something.
I didn't have anything to do with Proust.
My first (and only) startup, Metaplace, was sold to Playdom in mid-2010. A lot of people think we closed when we pivoted away from UGC virtual worlds, but we didn't. We did social games for six months before being acquired.
18 comments
[ 3.1 ms ] story [ 50.2 ms ] threadThe 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.
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).
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.
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".
Maybe not the guy to listen to anymore.
I didn't have anything to do with Proust.
My first (and only) startup, Metaplace, was sold to Playdom in mid-2010. A lot of people think we closed when we pivoted away from UGC virtual worlds, but we didn't. We did social games for six months before being acquired.
- 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)