Entry tags:
Entry tags:
Translations
From now on, I will translate some of my old LJ entries to English and publish them here. Such postings will be tagged "translated" and mercifully hidden under a cut.
( Still interested? )
( Still interested? )
Game mechanics at workplace
Some games are notoriously addictive. Can software development be, too?
An observation
Humans like their time structured. Addictiveness of games seems to stem from a system of tiered goals. A good game sports a full spectrum from split-second through medium-term to the extent of the entire game.
( UFO and Diablo II are two notable examples )
The mechanism
You're aware of all kinds of goals. Every short-term action can bring you closer to a long-term goal. If a particular shorter-term goal isn't very enjoyable you're still driven by the bigger goals, you know why you need to get past it.
To the contrary, Tetris has mostly immediate goals, few short-term goals, and no strategic goals except getting to the high scores table. It's easy to abandon a game if it's getting boring, unless your score is really high.
Comparison to software development
At grunt level, a developer has a bugtracker full of immediate goals, maybe a bit of short-term goals like having things ready to the time of the next release, and usually no long-term goals. Longer-term goals are handled by managers and maybe some of team leads. Bigger goals exist, but are invisible to mere developers.
You can make a longer-term goal from a bug-quashing competition or a race for a feature, but I rarely saw such things set up, and setting up and further handling by a clueful person is required.
The catch
The lack of longer-term goals makes it easier to distract and procrastinate. There's no important medium-term thing to care about. The short-term things are of limited importance, unless it's a rare critical bug. You can't constantly pedal the longest-term issues, too: e.g. an employee which is afraid to be fired any day won't do much good, and is prone to fleeing.
Mitigation strategies
* The cherished 'startup spirit' is very much about goal transparency: everyone sees the entire product evolve and cares about a next release or another feature.
* XP's journey from a complete mockup to a completely live system also helps see what's next, and probably even why.
* More?
An observation
Humans like their time structured. Addictiveness of games seems to stem from a system of tiered goals. A good game sports a full spectrum from split-second through medium-term to the extent of the entire game.
( UFO and Diablo II are two notable examples )
The mechanism
You're aware of all kinds of goals. Every short-term action can bring you closer to a long-term goal. If a particular shorter-term goal isn't very enjoyable you're still driven by the bigger goals, you know why you need to get past it.
To the contrary, Tetris has mostly immediate goals, few short-term goals, and no strategic goals except getting to the high scores table. It's easy to abandon a game if it's getting boring, unless your score is really high.
Comparison to software development
At grunt level, a developer has a bugtracker full of immediate goals, maybe a bit of short-term goals like having things ready to the time of the next release, and usually no long-term goals. Longer-term goals are handled by managers and maybe some of team leads. Bigger goals exist, but are invisible to mere developers.
You can make a longer-term goal from a bug-quashing competition or a race for a feature, but I rarely saw such things set up, and setting up and further handling by a clueful person is required.
The catch
The lack of longer-term goals makes it easier to distract and procrastinate. There's no important medium-term thing to care about. The short-term things are of limited importance, unless it's a rare critical bug. You can't constantly pedal the longest-term issues, too: e.g. an employee which is afraid to be fired any day won't do much good, and is prone to fleeing.
Mitigation strategies
* The cherished 'startup spirit' is very much about goal transparency: everyone sees the entire product evolve and cares about a next release or another feature.
* XP's journey from a complete mockup to a completely live system also helps see what's next, and probably even why.
* More?
Entry tags:
on preliminary training
If I were a coach in software development area, the first thing my trainees see would be a picture book for small children. They'd work in pairs: one describes a picture from the book, as fully and succinctly as he can, the other draws the picture, without looking into the book. Every time they work with a new picture. The process continues until everyone can tell everyone else, in reasonably short time, what to draw, and the resulting drawing reflects all the key aspects of the source picture.
Only after this it's time to talk about communication with customers, writing project specifications and so on.
Only after this it's time to talk about communication with customers, writing project specifications and so on.
