Different Perspectives

From my experience there are three main opinions when it comes to game conferences within game development (both indie and mainstream).

Shut Up and Code

I often hear people say they don’t have time to go to conferences as they want to make games, not talk about making games.  This opinion is particularly prevalent among programmers.  When laying out the entire costs of many of these events, they often make up a substantial proportion of an indie.  For this reason, many developers I meet simply don’t have the time or money to burn on conferences and most tell me they will go there “when they make it big”.

Networking, Networking, Networking

Another viewpoint I often see is from those that go to every event they can and give talks whenever possible.  To this group (often in marketing or management) the whole reason for making their game is to get it out there for people to see and play it.  This group will often miss all the talks/lectures and can instead be found walking the halls looking for new contacts or reconnecting with old ones.  A lot of value is achieved at most conferences from these people, none of it related to the speakers.  It is difficult though, particularly for the more introverted members of the development community.

I’ve found the best way to achieve the networking goal is make full use of whatever contacts you have (the higher the better).  You receive invitations to bigger and better parties and you’ll get more introductions.  The friends I went to GDC with introduced me to people working on Halo Reach, Mass Effect and a bunch of influential people attached to the Australian game industry.

Cost to Benefit Analysts

I fall into this group.  We are the people that list out all of the costs of going to a conference and weigh these up against the expected benefits.  I’ll dig deeper into this analysis and shed light on how you can quantify whether a conference is right for you.

Costs

It’s easy to quantify the costs of going to a conference.  The major costs are associated with time and money.  Below is a list of the costs I’ve found from the average trip to a conference:

• Conference Tickets (the cost of admission)
• Travel (airfare, insurance, taxi’s)
• Accommodation (hotel)
• Food (approximate per-day price)
• Drink (mountain dew and/or alcohol)
• Miscellaneous Expenses (passport, present to appease partner upon return)
• Lost time (per day cost of being away)
• Spending money*

*The further you travel the more you will spend on non-essentials.  I find I spend $100 per 1000km I am away from home.  For example I spent $150 on my trip to Melbourne and $1100 on my trip to the US (including Kennedy Space Centre)

Benefits

To determine the benefits of the conference, you really need to decide exactly what you want to get out of the conference.  The following list is an example of benefits:

• Networking – with potential clients, partners or existing friends
• Marketing – Showing off your current or next game or entering your game into competitions
• Information/Talks – Be critical with which talks are valuable.  Check the schedule and see how many are relevant or outside your comfort zone.  Also check reports of previous speakers
• Giving a talk – If you have something important to say, tell people.  Best way to network and market your game or company.
• Inspiration – This is a little hand-holdy and abstract however it can be the most important.  I come away from most conferences with a fresh outlook on game development and excitement about the possibilities.  If you are in a slump or unsure of the direction to take next, a conference can be the shot in the arm your team needs

Should you go?

To get a good idea of whether you should go to a conference, you need to map out what you want to achieve from the conference.  Of the benefits I’ve listed, some will be more important than others to you.  Unlike benefits, costs are easy for you to quantify and get a good picture of their total cost (which can often be surprisingly high).

Unfortunately you can’t easily assign a dollar value to the benefits to compare them directly against the costs.  You can, however, assign an importance for your business/game.  Look at each benefit you’ve listed and assign an importance from the following list:

• Unimportant – limited or no value to you
• Helpful – would be helpful, but not life or death.  An example is a talk that you could find the information for from the a textbook
• Critical – without this, your game may not succeed

If you have any critical benefits then you really should go to the conference.  If the majority of benefits are helpful then you should most likely go and if most are unimportant then perhaps your time could be better spent elsewhere.

Another good idea is to do this cost to benefit analysis for all the conferences in the coming 12 months.  You can then order the conferences from best to worst ratio and decide which you will and won’t attend.

Conclusion

What are your experiences from conferences?  Do you fit into one of the three groups I listed?  What’s been your favourite conference and why?  Can you recommend any conferences that others should go to?

Below is a short list on how I believe managers can foster a good software development team.

1. Fire bad programmers (and don’t hire them)

I decided to start with the controversial one; however it’s one of the most important. Nearly every team I’ve worked on has had someone on it that should have been fired but the company just wouldn’t do it. There are many benefits to be made from firing the bad programmers, some of which aren’t immediately obvious.

a. The obvious one is that bad programmers add bad code. This in turn causes more work for the rest of the team, adds to maintenance time and pushes deadlines back. This also leads to software entropy where good programmers will be forced to work with bad code which often encourages other bad code.

b. They bring the morale of the team down. Any good programmer can pick a bad programmer after only a few weeks of working with them. It’s very demoralising to be forced to work with someone that is no good, particularly if they are getting paid just as much, or more than the good programmers.

c. They teach bad habits. Keeping bad programmers on gives new programmers bad influences to look to for support. By letting them stay on within the team, managers are basically saying that they don’t mind having bad programmers working for them. It makes it hard to foster good quality coding standards when members of the team are openly ignoring them.

The only caveat to this is mid-development of a product. It may be detrimental in the short term to remove bad programmers immediately; however this often turns into apathy where the programmer simply stays on to the next project or milestone. Look at the schedule and actually mark off when the time is right to remove them. Once this date comes around bite the bullet and get rid of them.

2. Give rewards

I’m surprised how many programmers when asked how work is going will mention certain perks or rewards they receive from their bosses. This can be anything from having a few days off after record profits to free food/beer/game nights once a week. One of the biggest problems with ‘working for the man’ is that there’s no direct connection between the quality of work programmers do and their rewards. This was one of the key points in Office Space and every programmer I speak to has had this problem at some stage in their career. The main purpose here is to tie the success of the company to the employee’s that are creating this success. It can range from profit sharing to simply taking everyone out for a big meal (with free drinks for those inclined) after meeting a big milestone.

In the grand scheme of things it doesn’t end up costing much, and the productivity benefits returned will easily pay the rewards back many times over.

3. Give good direction

There’s nothing worse than having a project that’s just aimlessly drifting towards it’s goal. There need to be set goals that the entire project is working towards as well as sub-goals for each individual team. Programmers are logical, methodical people and they like order in their lives. The more you can make the project’s direction fit in with this view the more the programmers will ‘buy in’ on the future direction.

Programmers will look at the project as if it were a program in itself. There’s a bunch of commands the team is following (create the UI), with conditions (if there’s time, add in flashy feature 53) and iteration (each milestone). If you can learn to think like programmers do and show the direction of the project in a way they’ll understand you’ll see productivity gains.

4. Be transparent

I touched on this in an earlier post, so I’ll keep this one short. Basically let the team know what’s happening within the company. You don’t have to give them every detail, but make sure that the important information is propagated. This can be as simple as a company newsletter or an internal website that has the news. Those who are interested can stay up to date and others who don’t care can just ignore it. People often worry about their jobs and not knowing what is happening can often lead to a drop in productivity.

Conclusion

I’d like to hear from people if they have other ideas or whether people agree or disagree with my list. As things move forward with the business we’re hoping to set up a software team in the near future so I’ll start posting on how implementing these and other ideas I’ve blogged about works out in reality.