Games from Within

You’d think that things would slow down around Christmas time over here. And that I would have lots of time to catch up and write about all the things I keep jotting down in my overflowing “to write” list. Right? Unfortunately that’s not the case. I do want to catch up and share my iPhone development [...]

High Moon Studios is an unusual company in the games industry. We're applying agile methodologies for all of our development. My team in particular is using both Scrum (an agile management methodology) and Extreme Programming (an agile engineering methodology). And yes, that means we're doing pair programming, test-driven development, and all the other often controversial practices. I expect that in a few years, these practices will be a lot more common than they are today.

Pair programming really needs to be experienced to be fully appreciated. Just a few years ago, I loved my single office and I was completely against the idea of spending all my time programming with somebody else sitting at the same computer. Today I advocated using pair programming at work and I gladly gave up my office to work in a pair-programming lab alongside the whole team. Funny how things change.

Exactly a year ago today, I put up the first article on Games from Within. It was a review of Tom DeMarco's book Slack. I thought it would make for a nice, symmetrical bookend to wrap the year up with a review for another book by DeMarco: Waltzing with Bears. As the subtitle indicates, Waltzing with Bears deals with managing risk in software development projects. Managing risk, not reducing risk, or removing risk. Do you think that low risk or even no risk is a good thing? Think again.

"Wanted: Young, skinny, wirey fellows not over 18. Must be expert riders willing to risk death daily. Orphans preferred. Wages $25 per week." Pony Express advertisement, 1860. That would be a funny anachronism if it weren't still so true. In this second part f the article I argue that long hours in game development are not only something that could be avoided, but that they're actually detrimental to the project.