Being double-teamed: How to manage a team as a Double Developer

Welcome back everyone to the 5th entry in my "Life as a Double Developer" series. If you missed some of the previous ones, you can catch up here! I just want to thank everyone for their excellent comments so far; it's been very interesting for me to learn about other people trying the Double Developer life and the thoughts of others as well!

I'm a bit sleepy today after a hectic weekend preparing Waveform to be submitted to the IGF, so I apologize if this post is a bit more tired than usual! But without further ado, I'll dive into this week's topic: what it's like managing a team while working a day-job at another company.  So as cool as it would be if I were able to produce all of the art and music for Waveform (and apparently have 50 hours available every day to do so), I had to face reality that this just wouldn't be possible! So I had to seek out some other people that could lend me assistance. In the end I contracted out the art in the game and had some friends graciously offer their time and skills in helping me with level design and audio.

So the first difficulty when it comes to managing a team while working another job is that the time of day that we all work is completely different. If you've read my previous posts you know that I tend to do my work in the early evening and early morning before work. My level designer likes doing his work very late at night, and the artist works from home during the day since doing such art contracts is her full-time job. As you can imagine, this can lead to very poor communication! Not only are the vast majority of all our interactions done remotely to begin with, but the asynchronicity of it means most communication is done via e-mail. Although this is handy for having all of our notes and ideas in written format in case we need to refer to them later, in general it's a fairly impersonal and inefficient way to communicate. 

The primary trouble that this asynchronous communication causes is when one of us needs someone to take a look at something we're working on. For example, if the level designer wants me to take a look at a level idea or the artist needs me to put something in game to see how it animates, there's basically a 24-hour minimum turn-around time on such requests. I have to wait until I get home, retrieve their changes from the source control server, and check it all out in-game. And then, due to our different work-patterns, by the time I have things working the other person probably isn't around or available. So I can leave them a message and have them check it out the next day. But again, if any problems arise there's another 24-hour turnaround time penalty that we incur. 

This cycle of lost time is probably one of the biggest problems with trying to manage a team as a Double Developer. Progress in certain areas (chiefly those that require any amount of back-and-forth iteration) can drag behind quite significantly. The one saving grace with this would probably be that it's not quite as bad as lost time when working at a normal game development company. As an example, if some horrible crash bug is introduced in the game that prevents everyone in the company from working for an hour, there is a significant financial cost associated with that (paying people when they are blocked from doing their work) and a time cost since milestone dates are generally quite firmly established. But with Waveform, since people are using their free time anyway, they can just go enjoy their life for a bit and take a reprieve until the game is working again :)

Actually that brings me to an interesting point: what happens when I introduce a horrible crash bug into Waveform that prevents others from doing their work? As you can probably surmise from the description above, this generally means that the work slows to a crawl for the next 24 hours until I get home from work and fix the crash. Waveform has a level editor built right in to the game, which is a fantastic time-saver in my opinion and one that reduces iteration time on levels to essentially 0. However, the downside is that any crash in the game can make the process of level creation either impossible or a horrible exercise in frustration. 

A lesson I have learned from Waveform is not to take the graciousness of someone offering their time for granted! People don't want to have to spend their free time contributing to a game that is crashing at every turn and rendering their time meaningless.  Although it's hard enough for me to simultaneously develop game mechanics, a game engine, and a set of tools for level creation and asset production, doing rigorous QA on them is even more difficult. Nevertheless, this would certainly be a goal of mine moving forward onto projects after Waveform, a goal hopefully benefited by already have a game engine and a suite of tools in place.

And really, I think the real take-away from this post is that if you want to manage a team as a Double Developer, organization and preparedness are your best friends! Although it’d be fantastic if everyone I was collaborating with worked the exact same hours as me and thus were always at the ready for any communication that needed to be done, this really isn’t very feasible. Nor is it reasonable for me to ask it of others when they’re not getting paid until the game makes any money.

Unfortunately for me, organization is not my strong suit. My approach to game development is pretty fast and loose, which allows me to make prototypes and game mechanics very quickly. But it doesn’t translate well to trying to manage a team.

So in the future my plan would be to host an organized database wherein each contributor could find exactly what he/she needs to work on and the state of various things in the game. This would make communication about what needs to be done, and what is done, much simpler. Plus, providing some sort of repository for retrieving the last working build would do wonders for productivity when the latest version on source control is plagued by a crash bug. Which is a nice backup just in case my programming style doesn't become any more rigorous :)

Well I hope this post illuminated some of the headaches that come from trying to manage a team as a Double Developer. I actually learned some things about where I need to improve just by writing it! So it was very informative for me in that respect :)

As always, leave any comments or questions you have, and I hope you enjoyed this entry!