Estimates

I attended an IGDA meeting this past Thursday where the speaker tried to give estimates on how cheap it is to implement usability features. Her premise was that there’s no excuse why you aren’t implementing these usability features since they are so cheap. I’m not going to talk about that specifically, but how off her estimates were and how dangerous as a manager or producer it is to do these types of estimates without consulting an engineer.

First off, there are different ways to approach a problem. There’s the quick and “hacky” way and then there’s thinking through the problem. The best way is to think about the whole process and make it data driven. If, for example, we were going to implement a system for subtitles in our game. A series of questions you might think of are: how are the subtitles going to be entered by a producer? How are the subtitles going to triggered in-game? Are these subtitles going to need to be localized? Thinking about all these problems and leading towards a data-driven solution, will allow you to create a system which will stand the test of time. If you hack it in, the amount of maintenance you are going to have to do as this feature is used on several games, will be more cost then to implement it “the right way”. Now if you are going to be using the engine once, then hack away. However, in my 13 years in the game industry, I’ve never made a game where the engine was only used once.

Another variable are existing workflows and pipelines. Every studio has different ones and talking about an estimate for one studio doesn’t usually translate to another. Saving the button mappings for a controller is probably different for each engine. Having implemented this system before, it’s not that simple. Another factor is the engine itself. Madden and NCAA’s online play is deterministic. Meaning, the random number seeds are synchronized and only controller input is passed. What happens if you allow users to remap inputs? That now has to be taken into account and that original 3 day estimate you wanted to place on this feature is now double or triple that.

Another factor in this is motivation. I have never had any luck with estimates that were not made by the engineer who is doing the work. I have even had trouble when estimates are done by another engineer. That’s one of the things I like about iterative development. Estimates for the immediate milestone or sprint are done right at the beginning. This gives you a chance to adjust your schedule based on how accurate your original estimates were (velocity) and it gives a chance for the person who is actually doing the work to get their estimate into the mix.

The best way to attack this problem is through better designers who take usability into account when they are designing a feature. If you spent more time educating designers who know how to design these system, then this could be attacked in the design phase a feature. And what ever you do, don’t hand down estimates for an engineer to implement. That can lead to a project management nightmare.