Software development

Are you struggling with producing software and adding people doesn't seem to help? Do you have great people but it still isn't "getting done"? I included a snippet from a newsletter I subscribe to, it is interesting that though the four points defined below were not dictated at the start of the project, rather they were the result of the constraints placed on it.

-------------------------------------

by Shahar Larry from SIT Ltd. SIT is a
company that provides Systematic Inventing Thinking consulting and
training to companies around the world. They provide services to
companies such as Johnson & Johnson, Pearson and Bayer. Visit their
site at www.sitsite.com.

The Tower of Goo
Or how to Prototype a Game in less than 7 days: In this short list I would like to share with you a synopsis of an interesting case study I came across lately.

It's a game... a surprisingly simple game. All you need to do is to drag trash-talking, squirming and giggling gobs of goo in order to erect a tower. You must build it well and solidly or it will fall. The higher the tower, the better you score.

"Tower of Goo" was downloaded over 100,000 times within months of hitting the net (a remarkable figure in gaming-industry terms) and has received enthusiastic reviews from the net-gaming community. I tried playing it a couple of times. As simple as it might sound - there are no levels, you can't die, it is virtually never ending - it is neither boring nor easy!

But the interesting point for me about this story is that the Tower of Goo was created, designed and written in less than a week, by one person. Moreover, the same holds true for some 50 other games. All of these games were created as part of the Experimental Gameplay Project (www.experimentalgameplay.com) at Carnegie Mellon's Entertainment Technology Center.

The project started in the Spring of 2005 with the goal of discovering and rapidly prototyping as many new forms of gameplay as possible. A team of four graduate students (Kyle Gabler, Kyle Gray, Matt Kucic and Shalin Shodhan), worked in a room for a semester with three rules. Each game:

1. Must be made in less than seven days;
2. Must be made by exactly one person;
3. Must be based on a common theme, i.e. "gravity", "vegetation", "swarms", etc.

The four students published a comprehensive and detailed analysis of their achievement. Reviewing all of it might be a tad long, so for now I'll focus only on some aspects of the setup stage.

1. Constrain Creativity
The team's most successful games grew out of specific themes like "toys", or "gravity" or "swarming". As they report: "Somehow, it became easier to be creative when there were restrictions in place."

2.Enforce Short Development Cycles (More Time is not More Quality)
The team found that generally any gameplay idea could be prototyped effectively in less than one week. Extra time tends to yield diminishing returns. As they report: "Surprisingly, we found that there was no correlation between time spent in development and how successful the game ultimately turned out."

3. Gather a Kickass Team and an Objective
a. Kickass Team - Each member of the team was comfortable with all aspects of game development i.e. programming, art, sound, and everything else that went into the final product. Although development was done individually, the team did cooperate in what we might call "non standard team work" (see below).
b. Objective Advisor - The advisor's tasks, as he himself (Jesse Schell) testifies, were "To make sure that the team tried several different techniques... that the team was learning from their mistakes...that no one dwelled too long on an idea that wasn't working out... I gave suggestions along the way about how to improve the games as well, but mostly I tried to stay out of the way."

4. Develop in Parallel for Maximum Splatter
The minute the team was assembled, they stopped working with each other.

As it turned the benefits of not collaborating were too great to ignore:

-Risk Mitigation; By developing four prototypes simultaneously, the team could make risky design decisions with the comfort that at least one or two were likely to be successful.

- Friendly Competition; Everyone benefited from being kept on their toes. Like capitalism!

- Wider Thematic Exploration; Four minds all focused on the same theme forced the team to plumb the depths of each topic for fear they all make the same game. This forced the team into some rewarding creative realms avoiding obvious points of attack.

- Sharing and Caring; Though the team didn't share code (by choice, not requirement), they found it helpful to share concepts and understanding into a cumulative pool of knowledge. If one team member, for instance, discovered an effective way to represent spring systems, everyone would benefit.

- Non-standard teamwork; One of the interesting insights the team discovered was that teamwork was most valuable at the beginnings and ends of each cycle (week). In the beginning of each cycle, the team was useful for helping to solidify and compare ideas. At the development stage teamwork was more distractive than helpful. By the end of each cycle, the competitive flare of teamwork would again help finalize the work.


"The more constraints one imposes, the more one frees oneself of the chains that shackle the spirit. " - Igor Stravinsky (1882 - 1971), Poetics of Music

* * *
ASIT for new products development: http://www.start2innovate.com
ASIT for problem solving http://www.start2think.com