Setting Realistic Deadlines, Family, and Soup

(Cross posted from my personal dev blog site)

Jan. 23, 2015.  This is my goal. My deadline. And I'm going to miss it.

Let me explain.  As I write this article, I am also making soup.  Trust me, it all comes together at the end.

Part I: Software Estimation 101

I've been working on Archmage Rises full time for three months and part time about 5 months before that.  In round numbers, I’m about 1,000 hours in.

You see, I have been working without a specific deadline because of a little thing I know from business software called the “Cone of Uncertainty”:

In business software, the customer shares an idea (or “need”)—and 10 out of 10 times, the next sentence is: "When will you be done, and how much will it cost?"

Looking at the cone diagram, when is this estimate most accurate?  When you are done!  You know exactly how long it takes and how much it will actually cost when you finish the project.  When do they want the estimate? At the beginning—when accuracy is nil!  For this reason, I didn't set a deadline; anything I said would be wrong and misleading to all involved. 

Even when my wife repeatedly asked me. 

Even when the head of Alienware called me and asked, “When will it ship?”

I focused on moving forward in the cone so I could be in a position to estimate a deadline with reasonable accuracy. In fact, I have built two prototypes which prove the concept and test certain mechanics.  Then I moved into the core features of the game.

Making a game is like building a sports car from a kit. 
… but with no instructions 
… and many parts you have to build yourself (!)

I have spent the past months making critical pieces.  As each is complete, I put it aside for final assembly at a later time.  To any outside observer, it looks nothing like a car—just a bunch of random parts lying on the floor.  Heck! To ME, it looks like a bunch of random parts on the floor.  How will this ever be a road worthy car?  

Oh, hold on.  Gotta check the soup.
Okay, we're good.

This week I finished a critical feature of my story editor/reader, and suddenly the heavens parted and I could see how all the pieces fit together!  Now I'm in a place where I can estimate a deadline.

But before I get into that, I need to clarify what deadline I'm talking about.

Vertical Slice, M.V.P. & Scrum

Making my first game (Catch the Monkey), I learned a lot of things developers should never do.  In my research after that project, I learned how game-making is unique and different from business software (business software has to work correctly.  Games have to work correctly and be fun) and requires a different approach. 

Getting to basics, a vertical slice is a short, complete experience of the game.  Imagine you are making Super Mario Bros.  You build the very first level (World 1-1) with complete mechanics, power ups, art, music, sound effects, and juice (polish).  If this isn't fun, if the mechanics don't work, then you are wasting your time building the rest of the game. 

The book Lean Startup has also greatly influenced my thinking on game development.  In it, the author argues to fail quickly, pivot, and then move in a better direction.  The mechanism to fail quickly is to build the Minimum Valuable Product (MVP).  Think of web services like HootSuite, Salesforce, or Amazon.  Rather than build the "whole experience," you build the absolute bare minimum that can function so that you can test it out on real customers and see if there is any traction to this business idea.  I see the Vertical Slice and MVP as interchangeable labels to the same idea.

A fantastic summary of Scrum.

Finally, Scrum is the iterative incremental software development methodology I think works best for games (I'm quite familiar with the many alternatives).  Work is estimated in User Stories and (in the pure form) estimated in Story Points.  By abstracting the estimates, the cone of uncertainty is built in.  I like that.  It also says when you build something, you build it complete and always leave the game able to run.  Meaning, you don't mostly get a feature working and then move on to another task; you make it 100% rock solid: built, tested, bug fixed.  You do this because it eliminates Technical Debt. 

What's technical debt?  Well like real debt, it is something you have to pay later.  So if the story engine has several bugs in it but I leave them to fix "later," that is technical debt I have to pay at some point.  People who get things to 90% and then move on to the next feature create tons of technical debt in the project.  This seriously undermines the ability to complete the project because the amount of technical debt is completely unknown and likely to hamper forward progress.  I have experienced this personally on my projects.  I have heard this is a key contributor to "crunch" in the game industry.

Hold on: Gotta go put onions and peppers in the soup now.

A second and very important reason to never accrue technical debt is it completely undermines your ability to estimate.

Let's say you are making the Super Mario Bros. World 1-1 vertical slice.  Putting aside knowing if you game is fun or not, the real value of completing the slice is the ability to effectively estimate the total effort and cost of the project (with reasonable accuracy).  So let's say World 1-1 took 100 hours to complete across the programmer, designer, and artist with a cost of $1,000.  Well, if the game design called for 30 levels, you have a fact-based approach to accurate estimating: It will take 3,000 hours and $30,000.  But the reverse is also helpful.  Let's say you only have $20,000.  Well right off the bat you know you can only make 20 levels.  See how handy this is?!? 

Still, you can throw it all out the window when you allow technical debt. 

Let me illustrate:

Let's say the artist didn't do complete work. Some corners were cut and treated as "just a prototype," so only 80% effort was expended.  Let's say the programmer left some bugs and hardcoded a section just to work for the slice.  Call it a 75% effort of the real total.  Well, now your estimates will be way off.  The more iterations (levels) and scale (employees) you multiply by your vertical slice cost, the worse off you are.  This is a sure-fire way to doom your project.

So when will you be done?

So bringing this back to Archmage Rises, I now have built enough of the core features to be able to estimate the rest of the work to complete the MVP vertical slice.  It is crucial that I get the slice right and know my effort/costs so that I can see what it will take to finish the whole game.

I set up the seven remaining sprints into my handy dandy SCRUM tool Axosoft, and this is what I got:

That wasn't very encouraging. :-)  One of the reasons is because as I have ideas, or interact with fans on Facebook or the forums, I write user stories in Axosoft so I don't forget them.  This means the number of user stories has grown since I began tracking the project in August.  It's been growing faster than I have been completing them.  So the software is telling the truth: Based on your past performance, you will never finish this project.

I went in and moved all the "ideas" out of the actual scheduled sprints with concrete work tasks, and this is what I got:

January 23, 2015

This is when the vertical slice is estimated to be complete.  I am just about to tell you why it's still wrong, but first I have to add cream and milk to the soup.  Ok!  Now that it's happily simmering away, I can get to the second part.

Part II: Scheduling the Indie Life

I am 38 and have been married to a beautiful woman for 15 years.  Over these years, my wife has heard ad nauseam that I want to make video games.  When she married me, I was making pretty good coin leading software projects for large e-commerce companies in Toronto.  I then went off on my own.  We had some very lean years as I built up my mobile software business.

We can't naturally have kids, so we made a “Frankenbaby” in a lab.  My wife gave birth to our daughter Claire.  That was two years ago.

My wife is a professional and also works.  We make roughly the same income.  So around February of this year, I went to her and said, "This Archmage thing might have legs, and I'd like to quit my job and work on it full time."  My plan was to live off her—a 50% drop in household income.  Oh and on top of that, I'd also like to spend thousands upon thousands of dollars on art, music, tools, -- and any games that catch my fancy on Steam.

It was a sweetheart offer, don't you think?

I don't know what it is like to be the recipient of an amazing opportunity like this, but I think her choking and gasping for air kind of said it all. :-)

After thought and prayer, she said, "I want you to pursue your dream. I want you to build Archmage Rises."

Now I write this because I have three game devs in my immediate circle—each of which are currently working from home and living off their spouse's income.  Developers have written me asking how they can talk with their spouse about this kind of major life transition.

Lesson 1: Get “Buy In,” not Agreement

A friend’s wife doesn't really want him to make video games.  She loves him, so when they had that air-gasping indie game sit down conversation she said, "Okay"—but she's really not on board.  How do you think it will go when he needs some money for the game?
Or when he's working hard on it and she feels neglected?
Or when he originally said the game will take X months but now says it will take X * 2 months to complete? 

Yep! Fights.

See, by not "fighting it out" initially, by one side just caving, what really happened was that one of them said, "I'd rather fight about this later than now."  Well, later is going to come.  Over and over again.  Until the core issue is resolved.

I and my friend believe marriage is committed partnership for life.  We're in it through thick and thin, no matter how stupid or crazy it gets.  It's not roommates sharing an Internet bill; this is life together.

So they both have to be on the same page, because the marriage is more important than any game.  Things break down and go horribly wrong when the game/dream is put before the marriage.  This means if she is really against it deep down, he has to be willing to walk away from the game.  And he is, for her.

One thing I got right off the bat is my wife is 100% partnered with me in Archmage Rises.  Whether it succeeds or fails, there are no fights or "I told you so"s along the way.

Lesson 2: Do Your Part

So why am I making soup?  Because my wife is out there working, and I’m at home. Understandably so, I have taken on more of the domestic duties.  That's how I show her I love her and appreciate her support.  I didn't "sell" domestic duties in order to get her buy-in; it is a natural response.  So with me working downstairs, I can make soup for dinner tonight, load and unload the dishwasher, watch Claire, and generally reduce the household burden on her as she takes on the bread-winning role.

If I shirk household duties and focus solely on the game (and the game flops!), boy oh boy is there hell to pay.

Gotta check that soup.  Yep, we're good.

Lesson 3: Do What You Say

Claire is two.  She loves to play ball with me.  It's a weird game with a red nerf soccer ball where the rules keep changing from catching, to kicking, to avoiding the ball.  It's basically Calvin ball. :-) 

She will come running up to my desk, pull my hand off the mouse, and say, "Play ball?!"  Sometimes I'm right in the middle of tracking down a bug, but at other times I'm not that intensely involved in the task.  The solution is to either play ball right now (I've timed it with a stop watch; it only holds her interest for about seven minutes), or promise her to play it later.  Either way, I'm playing ball with Claire.

And this is important, because to be a crappy dad and have a great game just doesn't look like success to me. To be a great dad with a crappy game?  Ya, I'm more than pleased with that.

Now Claire being two, she doesn't have a real grasp of time.  She wants to go for a walk "outside" at midnight, and she wants to see the moon in the middle of the afternoon.  So when I promise to play ball with her "later," there is close to a 0% chance of her remembering or even knowing when later is.  But who is responsible in this scenario for remembering my promise?  Me.  So when I am able, say in between bugs or end of the work day, I'll go find her and we'll play ball.  She may be too young to notice I'm keeping my promises, but when she does begin to notice I won't have to change my behavior.  She'll know dad is trustworthy.

Lesson 4: Keep the Family in the Loop like a Board of Directors

If my family truly is partnered with me in making this game, then I have to understand what it is like from their perspective:

They are totally in the dark.  Now what is a common reaction to the unknown?  Fear.  We generally fear what we do not understand.  So I need to understand that my wife secretly fears what I'm working on won't be successful, that I'm wasting my time.  She has no way to judge this unless I tell her.

So I keep her up to date with the ebb and flow of what is going on.  Good or bad.  And because I tell her the bad, she can trust me when I tell her the good.

A major turning point was the recent partnership with Alienware.  My wife can't evaluate my game design, but if a huge company like Alienware thinks what I'm doing is good, that third party perspective goes a long way with her.  She has moved from cautious to confident. 

The Alienware thing was a miracle out of the blue, but that doesn't mean you can't get a third party perspective on your game (a journalist?) and share it with your significant other. 

Lesson 5: Life happens. Put It in the Schedule.

I've been scheduling software developers for 20 years.  I no longer program in HTML3, but I still make schedules—even if it is just for me.

Customers (or publishers) want their projects on the date you set.  Well, actually, they want it sooner—but let's assume you've won that battle and set a reasonable date.

If there is one thing I have learned in scheduling large team projects, it is that unknown life things happen.  The only way to handle that is to put something in the schedule for it.  At my mobile company, we use a rule of 5.5-hour days.  That means a 40-hour-a-week employee does 27.5 hours a week of active project time; the rest is lunch, doctor appointments, meetings, phone calls with the wife, renewing their mortgage, etc.  Over a 7-8 month project, there is enough buffer built in there to handle the unexpected kid sick, sudden funeral, etc.

Also, plug in statutory holidays, one sick day a month, and any vacation time.  You'll never regret including it; you'll always regret not including it. 

That's great for work, but it doesn't work for the indie at home.

To really dig into the reasons why would be another article, so I'll just jump to the conclusion:

After three months, I have not been able to come up with a good rule of thumb for how much programming work I can get done in a week.  I've been tracking it quite precisely for the last three weeks, and it has varied widely.  My goal is to hit six hours of programming in an 8-12 hour day.

Putting This All Together

Oh, man! This butternut squash soup is AMAZING!  I'm not much of a soup guy, and this is only my second attempt at it—but this is hands-down the best soup I've ever had at home or in a restaurant!  See the endnotes for the recipe—because you aren't truly indie unless you are making a game while making soup!

So in order to try and hit my January 23rd deadline, I need to get more programming done.  One way to achieve this is to stop writing weekly dev blogs and switch to a monthly format.  It's ironic that writing less blogs makes it look like less progress is being made, but it's the exact opposite!  I hope to gain back 10 hours a week by moving to a monthly format. 

I'll still keep updating the Facebook page regularly.  Because, well, it's addictive. :-)

So along the lines of Life Happens, it is about to happen to me.  Again.

We were so impressed with Child 1.0 we decided to make another.  Baby Avery is scheduled to come by C-section one week from today.

How does this affect my January 23rd deadline?  Well, a lot.
Will baby be healthy?
Will mom have complications?
How will a newborn disrupt the disposition or sleeping schedule of a two-year-old?

These are all things I just don't know.  I'm at the front end of the cone of uncertainty again. :-)

SDG

Links:

Agile Game Development with Scrum – great book on hows and whys of Scrum for game dev.  Only about the first half is applicable to small indies.

Axosoft SCRUM tool – Free for single developers; contact support to get a free account (it's not advertised)

You can follow the game I'm working on, Archmage Rises, by joining the newsletter and Facebook page.

You can tweet me @LordYabo

Recipes:

Indie Game Developer's Butternut Squash Soup

(about 50 minutes; approximately 130 calories per 250ml/cup serving)

Dammit Jim I'm a programmer not a food photographer!

I created this recipe as part of a challenge to my wife that I could make a better squash soup than the one she ordered in the restaurant.  She agrees, this is better!  It is my mashup of three recipes I found on the internet.

Peel squash, seed, and cut into small cubes.  Put in a large pot with broth on a low boil for about 30 minutes.

Add red pepper, onion, honey, ginger, nutmeg, salt, pepper. Place over medium heat and bring to a simmer for approximately 6 minutes. Using a stick blender, puree the mixture until smooth. Stir in whipping cream and milk.  Simmer 5 more minutes.

Serve with a dollop of sour cream in the middle and sprinkling of sour dough croutons.