PlayInFire
Why did the chicken play in the middle of the road?
Because there wasn’t enough challenge in getting to the other side.
Challenge-Seeking Developers
Last October, I posted a few thoughts on my old messageboard about “challenge-seeking developers”. I use that term to refer to the phenomenon where developers make every problem as intricate and involved as can be. Although in that message board entry I mainly covered the historical selection mechanism that set this vicious cycle in motion, I believe that there are several factors that hold it firmly in place:
- Over reliance on walled specialization - Where does a particular piece fit into the big picture? Is this important, or a trivial detail? Few people on a team know, when most developers only speak the jargon of their own line of work. Split every sentence in a book among a different writer, tell them each to write the best sentence they can, and you’ll wind up with such a mess that it can’t even qualify as a bad novel.
- We enjoy doing what we know - And who can blame them? Doing what we know makes us feel important. It’s self-validating. It’s a boost of confidence. It’s selfish. It’s about the developer, and done without regard for value to the end user. It’s a short-sighted delusion, it’s bad for a project’s focus, and it’s reckless with a project’s scarce resources. When engineers start theorizing about ultra-elegant or uber-accurate solutions for problems that are trivial to approximate, it’s a good sign that this is going on. When videogame designers break out board games and calculators, this is going on (unless, and this is strictly unless, they are working on turn-based strategy). When business people get together and start talking about the things they’re going to do to one up everyone else with an existing idea…
- It presents opportunities for learning - This one’s the rational clincher. Doing things the hard way presents a rare opportunity for focused skill development. Except there are two massive problems with thinking like this: (A.) by definition, it consists of developing a skill beyond the point of serving any practical purpose (B.) the skill gained across all such experiences, independent of whatever problem is at hand, is one of taking wastefully indirect routes to get anything done, meaning that at the end of the day there’s less real work from which to gain real experience.
The Danger
Making it across this dynamic maze - from blue to gold - is hard enough as it is. If the gold goal is never reached, then the accumulated experience is all for nil. As the player dallies, the chances of any of those scored points mattering falls away rapidly. A hint of success in meandering only circles back into gambler’s disease, in which no amount of success is enough until everything is lost.
History’s explorers could not come upon greater fame or fortune by extending their oceanic voyages, if roughing the extra difficulties resulted in never returning to shore.
The danger is that as these kinds of self-centered, disconnected exercises accumulate, money and energy wind up wasted on elements secondary to the project. As a side effect, the game as a whole winds up unfocused, or in some cases, unfinished.
What to do about it?
I can only speak from personal experience, and feel free to take these with a grain of salt, but…
- Make actual training a priority. This lightens the pressure to explore limits as tangent to the duties at hand.
- Execute on some smaller projects. It helps build muscle memory, it emphasizes that resourcefulness is worth more than resources, and it gives developers from different backgrounds more opportunity to take in the full process and lingo driving what everyone else does.
- Recognize the development process as a means to an end. Most people have zero interest in agriculture, medical research, automotive engineering, or computer chip design - but they certainly enjoy food, cures, cars, and computers. The same thinking applies. If the user won’t care, should the development team?
More points is a bad thing. Take a more reasonable route in PlayInFire.
February 2nd, 2008 at 4:18 am
I disagree that the game illustrates the point you seem to be trying to make.
Sure - fail to get to the other side and our points are 0. On the other hand, get to the gold and we’re doomed to never get a higher score. If our aim is to get a higher score, then on subsequent attempts at least, dallying is a good thing.
I did take away a couple of other ‘lessons’ from this game though
1 - nothing is certain. An auspicious situation can become a disaster in less time than it takes to react. We can stack the odds in our favour, but ultimately disaster can strike at any time.
2 - the goals we have are, generally, our own. This game almost demands that we decide a point at which to end our game - a point at which we can say, ‘that’s enough’. Like in real life, the quality of our work is often a result of our own drive, but we need to decide a point at which to stop and do other things. Although in real life, deadlines do help to suggest the quality goal, I suppose.
Maybe people find metaphors that apply more to themselves?
February 2nd, 2008 at 4:43 am
‘Aye, frankly I like your two better, and think they’re plenty well fitting.
I still think that it illustrates the intended point, however, in particular due to lesson #1 that you mentioned - there’s sufficient uncertainty that the options are, much of the time, scoot through and finish at all, or fail. Ship it as a mediocre product, or don’t ship at all; call the work of art done, or never share it with the public. At the very least, I think it highlights a very strange, seemingly contradictory reward/punishment system, and at that, one that maps to several things that I have going on in my life at any given time. (Like what gift to get someone. The longer I let myself think about it, the better the chances I’ll have a revelation… and the better chance that I’ll miss the intended date altogether.)
I think that deadlines also fit nicely into what you’ve identified as lesson #2. It’s basically someone else - a boss, a teacher, the government, whatever - saying that you need to wind up in that gold box with at least x points or else. Would it be overextending the metaphor to interpret from this an explanation for why deadlines, for many people, seem to yield work that’s “just good enough” to meet requirements? If more time or effort went into opening the problem space up further, there’s perhaps some concern that it might blow up on them and not get tied back together in time? I.e. if 80 points is someone’s goal, whether internal or external, then hanging around for 100 may be seen as putting the completion of the task at needless risk?