I think most of us on this forum can be described as "hackers." We love to dabble and learn as much as possible. We express short bursts of intense interest, where large amounts of progress is made, until we become bored again and move on. This can generally be seen in the large amounts of unfinished projects we all have, collecting dust on our harddrives. So my question is, what would be the most effective way to manage a team to capture this explosive development. I am currently the 'lead programmer' for Hero of Allacrost, and I find that our development goes in cycles. We have extremely talented and dedicated programmers, but we all lose interest quickly. Development occurs in short, explosive spurts, and then peters for a while, until the next spurt. Seeing as we only have 4 or 5 truly dedicated programmers, this often means that there are months where nothing gets done. Obviously, the simple answer is "suck it up, put your nose to the ground, and grind through it" -- but seeing as we are all doing this "for fun," I am hoping to find an alternative. ApochPiQ has good musings on a solution for the professional workplace, but how do these transfer over into the hobbyist world? Truly, many of us do not actually wish to become game developers, and game development is a way for us to flex our intellectual and creative powers. This also unfortunately means that it often takes a back seat. So what are the solutions? The Linux Kernal has a very good system in my mind, allowing contributers to send in patches. But can this work for a small game? Hardly. The core staff would spend far too much time looking over the contributers work. Plus, the game is not expansive enough a project to warrant all those contributers. Is more staff the answer? When does the old saying 'too many cooks spoil the stew' come into play? Does anyone here have any successful stories about managing a team of hackers?

Give them paychecks?

Quote: I think most of us on this forum can be described as "hackers." We love to dabble and learn as much as possible. We express short bursts of intense interest, where large amounts of progress is made, until we become bored again and move on. This can generally be seen in the large amounts of unfinished projects we all have, collecting dust on our harddrives.

Story of my life

>> We express short bursts of intense interest, where large amounts of progress is made, until we become bored again and move on.

That's fairly common, even in the work place.

>> Seeing as we only have 4 or 5 truly dedicated programmers, this often means that there are months where nothing gets done.

Months without progress means that they aren't wanting to work on your project, but would rather work on something else. That is a personal choice that they make since you aren't giving paychecks.

>> Obviously, the simple answer is "suck it up, put your nose to the ground, and grind through it"

The entire game making process is not fun. There are times when you have to go through the drudgery. There are parts that nobody wants to do. At work, you are assigned the task and you know you need to get through it if you want to keep getting paychecks. For a personal project it takes real dedication to get through those tasks, which is why so many personal projects remain unfinished.

>> Does anyone here have any successful stories about managing a team of hackers?

In a work environment, yes. Give a fun place, include ways to goof off and express creativity. Allow and even encourage breaks for having fun. Of course it needs to have a limited extent -- you still need to get the work done. Goofing off at work is one of the ways that the funnest ideas are found.

The big difference between a real workplace and people doing it as a hobby at home is the environment.

You have to be at work. You need to at least sit at your computer much of the day and look like you're working. You need to put out a certain amount of results, and that motivates you. If you don't do a certain amount of work, you won't get a paycheck. Part of that work includes the non-fun stuff. Those are the "suck it up and get it done" parts. The rest of it is fun, and you can usually find somebody around the office who really enjoys the task and wants that part assigned to them.

In a personal project at home, you don't have to look like you're working -- nobody cares if you spend the time surfing the web or playing games. Working on the "suck it up" parts is not fun so most people aren't strongly motivated to do it. In a personal project you don't need to produce any particular results, the only motivation is the periodic urge to work on it. If there are elements around that you are more motivated to do they will work on those instead.

1. Pay them, or
2. make them enjoy progress*

* Do development is small chunks with clear milestone deliverables and celebrate when they are achieved. If there is a big job coming up try to find some smaller jobs to run alongside which can be the milestone deliverables you celebrate while the big job is in progress.

Structure development to get to first playable as soon as possible. It may seem tempting to be working on everything at once and have 8 levels all in the engine but if they are all empty then the small victories will get lost in the large areas of boredom.

Thanks for the input guys. I didn't want this to be so specific about the team I am working with, since they are really a great team and do quite a fair bit of work. It was more just a general acknowledgement about the whole hobbyist industry.

Pay is not really an option, since these are hobby projects. I am more looking for "out of the box" thinking here, and less 'industry standard' stuff. Hence why I linked to ApochPiQ's journal entry.

I would really love to hear from some successful teams (4-5 people teams) about how they kept motivated.

Everyone in the team will feed off of you as the leader. If they see you putting in a ton of time it will motivate them to do the same. With that being said, I think that too much emphasis is placed on being a talented programmer. The ones who can complete and polish a piece of code are much harder to find...

Quote: Original post by visage
I think most of us on this forum can be described as "hackers." We love to dabble and learn as much as possible. We express short bursts of intense interest, where large amounts of progress is made, until we become bored again and move on. This can generally be seen in the large amounts of unfinished projects we all have, collecting dust on our harddrives.

That descibes me perfectly. Actually Ive found a way to induce these 'burst of intense interest'. I stay motivated by looking at other peoples work. Reading devlogs, looking at Images of The Day, and watching Cinematec and GameMakers on G4 is enough to motivate me. Not sure if it works for others though.

In the end I still have times where I stop programming for a while. After all if I was in permanent hacker mode game development would be a unhealthy obsession instead of a hobby.

I'm slightly different. I enjoy the little offshoot projects, but I use them to learn specific things (be it how to tune a physically simulated car, or how an art pipe for DX9 shaders should be done). Then I apply that knowledge in my actual work.

To manage a bunch of hackers, you need to have short, achievable milestones, and track progress according to the milestones. Commits that don't achieve progress towards the progress aren't billed in progress reports, etc. I've found that a SCRUM-like approach to task breakdown works well (although this is for people with paychecks -- I can see it working in free projects, too).

Also, test-driven development helps, because then whatever gets committed, has some chance of working, and keeping working. You may even be harsh enough to say that commits without test cases will be rolled back.

Then be clear about how status and goals is communicated in team meetings/irc/email etc. If the milestone for this month is "import one character from Blender and have it animate in place" then that's the focus of the meeting, and tasks related to that is what's available in the iteration task log.

Also, I've used XPlanner for tracking iteration tasks (not work backlogs), and it's worked pretty well.

http://www.stevepavlina.com/
http://www.lifehack.org/

Just browse some of the articles for a while; steve in particular has written quite a bit about improving productivity.