Best of Comments: Ad-hoc and GDC

It’s time again to highlight the people that keep us authors on our toes and instigate the excellent discussion that we really want as part of this blog.  I know I said I wanted this to be a weekly feature, but it looks as if we’ll be doing them a bit less frequent than that, which is fine.  But for now, on with the show!

Jay responds to my post on Ad-Hoc Tools Teams saying:

I want to argue that an ad-hoc tool team is ok provided the following:

• It is always good when an idea for a tools comes from the people who are going to use it.

• Even better, if they can come up quickly with an early implementation that is functional and effective.

• The official tool team can be shown what the tool does and why it is needed. Then the early implementation done by the ad-hoc team can be promoted to a fully featured tool with the support of the official tool team.

• The ad-hoc tool team understands that its main goal is to respond to a critical need (not to replace the official tool team if there is one).

I agree that giving the developers that are going to use the tools the ability to prototype them is an excellent idea.  An official tools team should never take the place of developers doing prototypes.  However, I think Jay gets to the heart of his issue with his last bullet point:  you can’t have your ad-hoc teams be support team, or worse the only tools team available to you.  Prototyping is always important, but once the prototype is proven, move it over to a team that can actually support the “product.”

On the same post, Ben asked the question:

[W]hat would you say are the main problems with permanent tools teams? Lots of people have had really bad experiences with centralized tools teams, especially at big companies.

I think this comes down to a cultural issue, and I see that it’s going to need a full post.  In general though, I think the biggest problem that comes along with centralized tools teams occurs because they’re not considered part of the larger team.  This hurst both your tools team (which feals left out) and your main team (which feals the tools team is aloof and unresponsive / uncooperative).  Always have members of your tools teams in close contact with the rest of the team (on the same scrums if you’re doing agile).  The helps bridge the gap between tools team and dev team, and will result in better communication and better tools.

Jay also posts another reason to consider contracting out custom tools developmen:

Often, developers need a tool right now to help with the game they are working on. Then, they move on to another project and the tool may be lost. However a contractor can anticipate the tools evolution with regard to game play, competitive requirements and technology progress.

Lastly, David asks about GDC:

Can you guys make an effort to grab any resources (slides) from these talks and post them here?

In certain cases, yes.  I’m sure Geoff will post the slides to his talk, and I will certainly post the notes from the Tools SIG Roundtable, but everything else is up in the air.  I will ask that, if you go to any of these talks, please send me your notes and I will be happy to post them!