Month: September 2014

The build succeeded… uh, yes, and…

The phone rings in the heart of the night. A sleepy programmer, tired for an extended period of hard work and long hours, wakes up and after a few attempts picks up the receiver. On the other side the slightly frantic voice of his boss: “Good news. The build succeeded…. oh, yes, and Jimmy has been kidnapped”. In fact, Jimmy (not the real name), a coworker and friend, had been kidnapped by two crooks while he was withdrawing at an ATM a couple of hours earlier. Luckily he was released in the night, naked in open country, but unharmed.
Well, I wasn’t there so I can’t say for sure if the conversation really occurred this way or if it has been “enriched” for the audience. But this situation came to mind recently because I start feeling that it captures quite well some peculiar traits of the videogame industry when compared to the software development industry at large.
In my experience, and surfing the internet also to many other experiences as well (see this, this, or this, or just google for more results), most game development projects turn into a nightmarish run for your life against the deadline. The only certainty is that you and your loved ones are going to pay an exaggeratedly high price for you “making games”.
Family, health, friends, life, nothing matters when confronted with The Game. You can’t plan a vacation with your family, you can’t go to the gym, you can’t be home to be with your children or your wife, but hooray the build has succeeded.
But why? Why has to be like this in the videogame industry? While industry and academia have developed methods and strategies to improve project management relieving workers, reducing risks and improving quality, why the game industry fails so epically to be a saner environment?
Of course every project, regardless of the industry, has to be profitable and economically viable. And the justification I often heard is that if you are late then you can only work longer to hit the target. You have only to agree, but this is just denying the value of planning. Is like to say if you are outdoor and starts raining you can only get wet. Yes. At that point, you don’t have any other option. But a good planner likes to be prepared and would have brought an umbrella.
As any project management book will tell you, projects are defined by three variables – time, resources, quality. Time is, well calendar time needed to complete the project. Resources are the people working on the project and their tools. Quality is the quality of the product that can also be seen as a list of features.
Of these variables only two can be set, the other one is given. That is, you can set the target quality and the time, but then the resources count is derived and cannot be forced. If you attempt to fix all three variables, then the project will be understaffed or late or shoddy, possibly all three.
The agile process doesn’t do any magic, it is just chopping the project into smaller projects with more flexibility on the feature list. A sane agile project will scrap features that don’t fit into the iteration and those that add the least value to the project. This is known also as de-scoping and it is something that I found extremely hard to do on a game project planning.
My impression is that, aside from the basic mismanagement, in the process of developing a game too much passion and too strong emotions are involved. It is not just being passionate about your own work, it is something more akin to religious devotion. In my past experience, people had a brawl because of the misappreciation of an artist’s work.
So, if the videogame is, after all, a work of art and art is about emotions and feelings, is it possible to make games and work in a sane environment?