Project overrun and the difficulties encountered when trying to accurately predict development time still brings the finest war stories to any IT Christmas party table. Over the years, numerous methodologies have been developed to tame the beast, but with software still the adolescent of engineering, the dark art of estimation remains elusive.

Image alt

As a developer who is drawn to those romantically told war stories forged in the quiet cubicles of industry, part of me kinda likes it that way. A shocking confession perhaps, but in my head the orderly world of left-brain logic will always long for the great unexplored chaotic space of imagination. In some ways, it is the occupational necessity for both of these that makes the IT department the most romantic, humorous and fun bunch of dreamers in the cold world of carpeted cubes.

In recent years, the issues of vague requirements and incomplete proposals have been somewhat addressed by the addition of that layer of people between IT and the rest of the world. But despite this progress, we have all seen the look of fear in a developer’s eye when the question ‘how long it will take’ ripples across the morning stand-up meeting, powering towards them like a Mexican wave of guesses and preemptive overestimation.

##with undoubtedly late nights, we usually hit the target – there or thereabouts.

We’ve all done it – aired on the side of caution, made a quick estimate without knowing where we’d start and then added a few days ‘just in case’. Of course the more confident you are, the easier it becomes to ask for more time or demand more specifics. But with varying degrees of competence, confidence and out-and-out optimism on any given team, when all estimates are pulled together they will usually contain a few land mines. And so with a balancing act of cautious early estimation and frantic late re-estimation, by the seat of our pants and with undoubtedly late nights, we usually hit the target – there or thereabouts.

Image alt

Estimating for oneself however, now that’s a whole different story. Cover-ups and management-pleasing are no longer required. You are free to be totally honest with yourself, even if that means admitting “I haven’t got the foggiest notion”. Of course you still need to make a stab at it for your own sanity – and it was this stabbing that taught us a lot about what is required to get it right.

Before making Primal Flame, we did not have Industry experience managing a full project life cycle and were unfamiliar with the freedom and responsibility that comes with manning ones own vessel. So how did it go..? Our initial estimate was wildly inaccurate, with the final release having 100% overrun on our original estimation. But why..?

We had minimal experience with iOS development, even less with game engines or animation and for reason outlined in another post, our design was not fully envisaged before we started. But as it turns out, our biggest mistake in estimation came not from these obvious stumbling blocks but from a hidden factor – Emotion. Our original estimation was actually a reflection of ‘when we would have ideally liked to be finished’, ‘when those around us would have expected us to be finished’ and ‘how long we thought we could do this for’. We estimated with our hearts and not our heads.

###We estimated with our hearts and not our heads.

Making our first game has taught us a lot about getting involved in long-term projects. You must be prepared for the long haul; to see it through even if the ‘proposed’ finish line fades into the distance behind you; to be honest about how long it will take you to produce something really great. No matter how much you want to feel like a fast coder or a genius designer, casting aside your emotions and focusing on the cold hard facts will serve you well in the long run.

Whether we have truly learned to remove the last minute panic and serious all-nighters from our development cycle remains to be seen, but at least this experience has given us one more great war story for the Christmas party table :)