Projects – Development vs Production

It’s kind of strange, but everytime I’ve been through the development cycle of any game I always here someone complain that “we should have planned better”.  Or perhaps we should have “designed better”.   They are tough accusations to defend against.  After all, what can’t be done better?  But those comments always seemed to me to be off the mark, missing something important about the development process.  In a similar vein defensive comments like, “It’s hard to schedule innovation.” also seemed to miss the point.

So what is it with project management, process, and project planning? 

This morning I had a soup to nuts project management experience with my six year old son that put some stuff in a clear light.

First, let me explain the difference I see between development and production.  Production is something you’ve done before… many times.  “Flipping” burgers, assembling cars, are tasks that I largely view as production tasks.  Things that are well understood, processes that have been tried and proven many times, and optimizations (along with cost reductions) are a key focus of creative thinking and engineering effort.

Key questions asked for mature productions are:

  • “Can I do it faster?”
  • “Can I do it cheaper?”
  • “Can I improve quality?”
  • and “Can I improve consistency?”

Development is also concerned with these questions, but typically these questions get relegated to the back burner.  One single burning question typically dominates the development project.  Namely:
“How Am I going to do this?… at all.”

Development is of course almost never completely new, but it often attacks problems, or projects that the team has little or no direct experience solving.  It leverages the teams strengths, builds upon what they know, but almost always involves fundamental changes in process, production, or understanding.

Put another way, Mature Productions are applications of “what is known.”  Development, in my exerience is most often about “learning how”.

So, let me give a specific example and see if this helps.

My son wanted a skate board ramp.  Have I ever built a skate board ramp before?  Nope.  Not one.  But I’ve built lots of stuff.  I have tools.  I’m pretty sure I know how to use them.  But I dont have a tried and true process for building skate ramps.

So I took the opportunity to teach my son about project management.  I told him, here’s the steps to managing any project.

First, we start by knowing what we want. – Skate Board Ramp.

Then, I told him, here are the steps to managing any project.

  1. Design it.
  2. Plan it.
  3. Build it.
  4. Test it.
  5. Clean up afterward.

There were two important things, I said that were missing from my short list, between 3 & 4.  LEARN, and ADAPT.  To me they are integral parts of steps 3 & 4.

So, step 1 – design it, was done using Google Sketchup.

I sat down and quickly “sketched” out a ramp using the materials I knew we had on hand.  I’d had some experience with this in the recent past and really liked Sketchup as a design tool.  It made it super easy to figure out what angle I needed to cut the support legs (10 degrees), so there was little or no guessing when it came time to cut the wood.

I talked to my son once I’d finished the first draft of the design and in that process two more things popped up.

  1. Always check with the customer during the design phase.  Once they get an idea of what you are trying to do, requirements almost always change as THEY learn more about what they want.  Basically, you should test your design.
  2. Present information to your customer in a way that makes sense to THEM.

As you can see from my image, the ramp is show upside down so it shows what I (the developer) cared about most – the underside of the ramp and the structure I had to build.  It wasn’t easy for my son however to see how he could jump off the skinny little posts.  So I re-rendered the drawing with the dimensions removed and the ramp placed right side up.  He was much happier.  He also wanted it taller – 9 inches high instead of 6.  So I quickly made those changes, printed the drawing and we were ready for the next part.  The plan.

Together we wrote out the plan.  It looked something like:

  1. Put on our safety gear (goggles and gloves)
  2. Gather our materials. (get the wood)
  3. Measure the cuts.
  4. Cut the wood.
  5. Assemble the ramp.
  6. Test the ramp.
  7. Fix anything that needs fixing.
  8. Clean up.

With that plan in front of us, we set about making our ramp.  Now one thing conspicuously absent was the lack of time information.  I didn’t really know how long it would take us to do all of this, but I suspected it would be about an hour project.  An hour should be plenty of time.  Of course it wasn’t, but we’ll see why in a minute.

Stuff changes:

We put on our safety gear with no problem, then quickly moved to step 2.  Gathering the materials.  Right away the design started to change.  First of all, once I started handling the materials I realized that using 2×4’s for the legs might not be as stable as I wanted.  I had a pile of 4×4’s which I decided to use instead.  So almost out of the gate the design was changing.  And this is extremely common in development.

Designs must adapted to the resources available.

I personally have never seen a development project that had EVERY resource it ideally needed available to it.  There is always some constraint, or new information that comes along to cause change.  Our ramp was no different.

Secondly, when I designed the ramp, I used the information I had available (namely dimensions), but the actual wood available varied somewhat from my initial estimates.  This brought up another thing I’ve seen in projects.

Designs adapt to integrate new information.

In construction there’s a term called, “as built” and it refers to the way the contractor ACTUALLY BUILT the design.  Not the way the architects drew it.  In the HBO series project Greenlight, I remember after the end of principle shooting, someone saying, “Okay, now lets find out what movie we’re going to make.”  Their point was just this, the movie they intended to make when they filmed, and the movie they ultimately ended up making were not necessarily the same.  The realities of filming, caused changes that could not necessarily be undone later.  Once the filming was done, the director (and editors) had to make the best possible movie out of the materials that had at hand.  Regardless of what they wanted to do originally, they would adapt the design to the resources available.

Our little project was demonstrating these adaptions.

After measuring and cutting the wood, we started to put the thing together.  Again more assumptions were tested, more changes were made and more problems ensued and were quickly solved.  For example, the screws that were supposed to hold the wood in place were too short.  We needed longer ones – but not so long that they would go through the 2×4’s.  We scrounged up a suitable substitute.

Tuning 

After assembling the ramp, we tested it slightly by walking on it and realized that there was too much flexing of the plywood.  It needed just a wee bit more support.  All in all the design was great, but we were all worried the wood would crack after a few jumps.  So back in we went – to add 10 degree angle blocks in front of the 2×4 supports to keep the front of the ramp from flexing.  In game development we often call this “tuning” making small changes to the design to improve it’s performance and the users’ all around satisfaction.

In programming, there are “optimizations”.  The thing runs, but not fast enough, or with too many system resources, or just not well enough.  So we “optimize”.  Make small (but significant) changes that improve the overall quality of the project.  That is the heart of development.

Development is about iteration – making small changes to improve the quality of the project. 

We also noticed that even with our thick legs, they wobbled too much.  They needed braces.  Angle braces (left over from another project) were quickly called into service and the screws that were too short before worked out perfectly in their new application.  It is very important to note here that we did not scrap the whole thing and start over when we ran into problems.  The plans changed as we adapted to our resources, and learned new stuff, and the changes were relatively small.  Development seems to be about progressively circling in on your goal.  Development is not taking wild stab after wild stab.

Final Review

After we finished, we cleaned up, put our tools and materials away, then played with the ramp.  It was fun.  Then we put the ramp way.  Later, we made one last change.  Putting the ramp way, revealed that it was HEAVY.  Watching my 6 year old son struggle to put his new toy away, I realized he needed some help.  Finding a set of left over casters, we attached them to the side of the ramp so all he had to do was wheel it in and out of the garage.

The final ramp, looked as follows:

 

 

A few things I did learn during the project. 

A few things I did learn during the project. 

A few things I did learn during the project. 

A few things I did learn during the project. 

  1. With no time estimates, it was easy to lose track of time.  The project actually took an hour and 45 minutes.  But fortunately time wasn’t the critical factor.  That is not always the case.
  2. While my son was involved and feels that the project was “his”, without a detailed task list to keep him engaged, he would often wander away.  The same thing happens with adults.  Without a clear list of actions to keep team members engaged to work toward a goal, they will at best do nothing of value, and worst, do things that are counter productive.
  3. Finally and most importantly, building a skate ramp with your son is a blast.

 

 

My point in all of this, is that not on the second time, but probably the third I would start to build ramps pretty much the same way.  I would work out the kinks, and the mystery of “how” I would build the ramp would receed.  The questions at the beginning of my essay would move to the fore front of my thinking and I would start to have a “mature production”.

So after all of this, I think the key to managing a successful development is not to whine about better planning or design, but to ask, “how can we learn faster?”  Because that more than anything seems to be the central theme of development.

– Scott

Fall Line Studio

As recently reported I am now running Fall Line Studio in Salt Lake City for Buena Vista Games, a part of the Walt Disney Company.  Fall Line – a snow boarding term which means, “the most direct path down the mountain” – will be a Nintendo Center of Excellence for the BVG.  For the many of you who have contacted me looking for positions with the new studio, we are hiring, but competition is fierce for every position.

 I want to thank everyone who has contacted me for their kind words of encouragement in starting this new studio, and I wish everyone who has applied the best of luck in their careers either with (or without) the Walt Disney Company.

 

Scott

The Gaming Generation

Many of the people I meet who are familiar with the video game industry only through the mass media, often have a very skewed perspective on what video games are and what they are all about. I often recommend to them a book called “Got Game” which provides another perspective on video games in our culture.

One of the key things that falls out of this book is the premise that games have created a true generation gap. Forget Gen X, Gen Y and all that. There are boomers and there are gamers. If you grew up before the Atari 2600 you have one view of video games. If you grew up with the Nintendo SNES, Sony Playstation, or more advanced systems you have a very different view of games.

What’s interesting about this book is that it articulates certain values and attributes of the gaming generation. Namely that they are:

  1. Fearless. There is no penalty for failure. If fail you just hit restart. No big deal.
  2. Trial and error is the best teacher. This results in a corraly which so many parents, adults and authority figures find disturbing; and that is no (or little) respect for seniority or authority. It’s not anarchy, it’s just that when these kids were growing up NO ONE OLDER THAN THEM knew anything about what they cared about most. Video games. Imagine growing up playing Piano but there were no Piano teachers, no masters, no one to follow. For practically all of the 90’s this was the case. You had to figure it out for yourself.
  3. ROI Machines. Gamers are all about getting it done faster, better, with less effort (cheaper). They are ruthless in their drive to optimize.
  4. True Meritococrats. Gamers value skill above all else. They are so used to looking at avatars that race, creed, background are irrelevant to them. They may not know where their opponent sits, what they look like, or how they dress, but they know what they can do and THAT they respect.
  5. Value Diversity. Go into an online dungeon with 5 warriors and your party will get wiped out. Go in with a well balanced team (the holy trinity of Healer (cleric), Tank (warrior) and Damage Dealer (wizard) and you will dominate.
  6. Great Team Members. Solid team play is more effective than individual skill. Clans in games like counterstrike, or World of Warcraft Battlegrounds always overcome the talented but disorganized opposition.
  7. Altruists. The games are almost never about the money. They are about saving the princess, or the world. However, if money is how score is kept then gamers will maximize that. They keep score, but the motivation to “win” is often very different from the world their parents grew up in.
  8. Relentless. Gamers feel they wouldn’t put you in a level (or a job, or a situation) unless you could complete it. You just have to stick at it long enough (that Trial and error thing).

These are just some of the lessons of the gaming generation. And I find them to be particularly interesting. But the real point of the book is how to change your management style to more effectvely employee people with these common attributes because what is so surprising is that the common thread is no longer race, creed, geographic location, but game experience.I highly recommend this book it’s worth a read.