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.

Switching to Android

HTC-EVO-b-300x504 I’ve always been an early adopter of technology. I have about six months left in my AT&T mobile phone two-year commitment and I will probably be switching carriers. I intentionally didn’t pre-order the new iPhone 4 and I will be switching to an Android based phone once my contract is up.

The main reason: I can’t stand Apple products. Their interface isn’t intuitive to me. Maybe it’s my long term use of Microsoft products. Let’s take iTunes as an example. I’m constantly fighting with that program and it never does what I expect it to. With the resent upgrade to iOS 4, I couldn’t figure out how to create a new folder. I was looking for the “New Folder” button. I had to find out from someone else that the way to create a folder is to drag another icon onto another. Their products are just not intuitive to me.

Another reason is that I have to buy a Macintosh computer if I want to write a program for the phone. Now that I mainly manage people and my job doesn’t include computer programming, I have to scratch that particular itch at home. With an iPhone, the requirement of only being able to create Apps on Macintosh is not practical. With the switch to Android, all I need to do is learn Java and the Android API and I can put self-authored applications right on the phone. This isn’t possible with the closed iPhone even if I did have a Macintosh. Well, I’ve already started plodding my way through a Java book looking at the differences between that language and C++.

Anyway, good luck to all the iPhone users out there. Don’t forget to hold your iPhone properly so that you don’t have any dropped calls.