Search

Tuesday, November 29, 2011

Why we should stop saying "vertical slices"

The other day I came across the this blog post by Ron Gilbert called The Vertical Slice in which he rails  against the creation of vertical slices.  The following quote struck me:

"Vertical slices might work in a medium where you start at the beginning and grind though in a fairly linear fashion and what comes out is 90% complete.  Maybe writing a novel works this way, but making movies and games do not.  They are an iterative processes.  You build foundations and the build up from there."


I love his image of the Mona Lisa's vertical slice.   But Ron is using a different definition of vertical slice than I've always used.  To me a vertical slice means is that we develop a feature to the point of knowing its value and use that knowledge to adjust the plan.  The point being that the plan won't tell you how fun something is: the game will.

Ron's definition is that vertical slices emerge from a plan that defines all the slices up front.  This might be a better approach from an engineering point of view over waterfall (fixing bugs along the way, etc), but  it abandons the benefit of iterating on a plan with a working game.  It doesn't surprise me that he's against that.

So maybe we should stop using this confusing phrase.  Maybe we should call it a "game increment", or something.  I'm open to suggestions.

By-the-way, here is how portraits were iterated on:

Do a Google image search on "unfinished portraits" and you'll see a lot of these, all with the heads nearly completed and little else in the portrait done.  Can you guess why?   It has something to do with prioritizing risk, and stakeholder value....things often spoken about in agile circles centuries after this was painted.

Also, da Vinci iterated on the Mona Lisa as well.

Tuesday, November 01, 2011

More on specialization


My recent post on specialization has ignited a bit of argument with people on one side saying that I've "come out against learning" and specialists who didn't like my use of their UI/database specialties as a poor example (if I die in a suspicious UI/database related incident, my post is to blame).

The point of the post was that we should encourage "multi-learning" or more cross-specialization without seeking to homogenize all specialization.  The point of the "anti-specialists" is that a graphics programmer should learn more about physics programming.   There are benefits, personally and professionally, to doing this.  There are common solutions in both and insights that crossing boundaries can create.  I agree.

On the other side, many deep specializations take, as Malcolm Gladwell wrote, over 10,000 hours of practice and an innate skill to achieve mastery.  I use the example of musicians because as a untalented amateur musician, there is no way I am going to become skilled enough to even write 10% of the music that a game needs.  However, having worked side-by-side with them and learned their workflow, I can still help them do their job.  Having learned about mixing and composition a bit, I have widened my world and appreciate game sound tracks a bit more.

We often specialize far too much.  For example, some studios have specialized QA to the point where a programmer just has to hand off barely compiling code and someone else integrates it.  QA should be the more the responsibility of everyone creating the game.   Everyone on the team should care about quality.  It shouldn't be a role.

We should also learn more about every surrounding role, every day.  We each shouldn't be just a specialist cog in a development machine.  We should be "game developers" first and [fill in the blank] specialists second.  How many games have you seen or worked on where its apparent that one area of specialization dominated and ignored the rest of the game?