Comments on: The Problem With Ad-Hoc Tools Teams http://thetoolsmiths.org/2009/02/03/the-problem-with-ad-hoc-tools-teams/ Mon, 16 Aug 2010 17:08:37 +0000 hourly 1 http://wordpress.org/?v=3.0.1 By: Best of Comments: Sweat and Development « The Toolsmiths http://thetoolsmiths.org/2009/02/03/the-problem-with-ad-hoc-tools-teams/comment-page-1/#comment-353 Best of Comments: Sweat and Development « The Toolsmiths Tue, 03 Mar 2009 18:11:35 +0000 http://toolssig.wordpress.com/?p=79#comment-353 [...] was my major argument against ad-hoc tools teams. Jeff Massung, however, responds with an actual answer to the question: Certainly the “not [...] [...] was my major argument against ad-hoc tools teams. Jeff Massung, however, responds with an actual answer to the question: Certainly the “not [...]

]]> By: Nick http://thetoolsmiths.org/2009/02/03/the-problem-with-ad-hoc-tools-teams/comment-page-1/#comment-352 Nick Mon, 16 Feb 2009 21:03:30 +0000 http://toolssig.wordpress.com/?p=79#comment-352 In case you're interested, I presented a course at Siggraph in 2007 on tools development strategies, and discuss how ad-hoc tools fir into the overall evolution of an organization. I focussed on issues and developments we encountered on the development of The Force Unleashed. http://meshula.net/wordpress/?page_id=100 I talked about the scenarios under which an ad-hoc pipeline arises, pros and cons, how it evolves, and a way to incorporate ad-hoc development and tools into a mature pipeline. A lot of it seems relevant to the discussion here. In case you’re interested, I presented a course at Siggraph in 2007 on tools development strategies, and discuss how ad-hoc tools fir into the overall evolution of an organization. I focussed on issues and developments we encountered on the development of The Force Unleashed.

http://meshula.net/wordpress/?page_id=100

I talked about the scenarios under which an ad-hoc pipeline arises, pros and cons, how it evolves, and a way to incorporate ad-hoc development and tools into a mature pipeline. A lot of it seems relevant to the discussion here.

]]> By: Jeff Ward http://thetoolsmiths.org/2009/02/03/the-problem-with-ad-hoc-tools-teams/comment-page-1/#comment-351 Jeff Ward Tue, 10 Feb 2009 15:01:55 +0000 http://toolssig.wordpress.com/?p=79#comment-351 A good question, and one I'll have to probably dedicate to another post, but the gist of it will be: Formalize your tools team, staff it reasonably for the teams its supporting, but always integrate your tools team with your game teams. The tools team needs to be a visible part of the game team so that communication between both teams doesn't halt. It's another culture issue, but I'll talk about it briefly in another post. A good question, and one I’ll have to probably dedicate to another post, but the gist of it will be: Formalize your tools team, staff it reasonably for the teams its supporting, but always integrate your tools team with your game teams. The tools team needs to be a visible part of the game team so that communication between both teams doesn’t halt.

It’s another culture issue, but I’ll talk about it briefly in another post.

]]> By: Ben http://thetoolsmiths.org/2009/02/03/the-problem-with-ad-hoc-tools-teams/comment-page-1/#comment-350 Ben Tue, 10 Feb 2009 01:28:30 +0000 http://toolssig.wordpress.com/?p=79#comment-350 Jeff, flipping the post around, what 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'm looking at you, Sony and EA but I can't comment on Nintendo and Microsoft). Jeff, flipping the post around, what 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’m looking at you, Sony and EA but I can’t comment on Nintendo and Microsoft).

]]> By: Jeff Ward http://thetoolsmiths.org/2009/02/03/the-problem-with-ad-hoc-tools-teams/comment-page-1/#comment-349 Jeff Ward Sun, 08 Feb 2009 19:03:03 +0000 http://toolssig.wordpress.com/?p=79#comment-349 @Jay: You're right, a formalized tools team can (and frequently should) be supplemented by other programmers doing prototypes. So long as the people doing the prototypes realize they're just prototyping the tool, you're in good shape. Of course that comes down to really talking about prototyping in general, which is a huge discussion on it's own. @PH: The problem you're talking about comes up not just in tools dev but when you have things like an "engine group" or "systems group" as well. you have to be careful about how things are structured and make sure everyone's needs are met at all times. This comes down to a company culture problem more than a best practices problem (IMO). That said, structuring your tools team "correctly" can help the problem. But how you structure it depends on how you run your company. If you have a lot of games being made simultaneously that share tools and engines, you may want a company wide tools team supporting all projects for things like editors, which are shared by all games. In addition to that though, you may also need small tool "strike teams" on each individual game team to support specific needs and as part of your individual scrums (if you're doing agile). So long as the strike teams and the main tools group are in communication and not duplicating functionality, you should be golden. @Jay: You’re right, a formalized tools team can (and frequently should) be supplemented by other programmers doing prototypes. So long as the people doing the prototypes realize they’re just prototyping the tool, you’re in good shape. Of course that comes down to really talking about prototyping in general, which is a huge discussion on it’s own.

@PH: The problem you’re talking about comes up not just in tools dev but when you have things like an “engine group” or “systems group” as well. you have to be careful about how things are structured and make sure everyone’s needs are met at all times. This comes down to a company culture problem more than a best practices problem (IMO). That said, structuring your tools team “correctly” can help the problem. But how you structure it depends on how you run your company.

If you have a lot of games being made simultaneously that share tools and engines, you may want a company wide tools team supporting all projects for things like editors, which are shared by all games. In addition to that though, you may also need small tool “strike teams” on each individual game team to support specific needs and as part of your individual scrums (if you’re doing agile). So long as the strike teams and the main tools group are in communication and not duplicating functionality, you should be golden.

]]> By: PH TRIVIER http://thetoolsmiths.org/2009/02/03/the-problem-with-ad-hoc-tools-teams/comment-page-1/#comment-345 PH TRIVIER Fri, 06 Feb 2009 10:55:08 +0000 http://toolssig.wordpress.com/?p=79#comment-345 @Jeff : Thanks, sorry to ask you to repeat your point once more ;) Would you advise to a have a dedicated tool team for each project, or one company-wise ? It makes sense to have only one tool team (tool sharing, avoid reinvention). But then this team need to provide tools to several projects and it might delay the actual production of the tools, hence delaying the work of every team ... leading to ad-hoc teams recreating themselves as it's "impossible to get things done from those tools dev". Ever seen that happen ? Is it sustainable in game dev world ? Regards PH @Jeff : Thanks, sorry to ask you to repeat your point once more ;)

Would you advise to a have a dedicated tool team for each project, or one company-wise ? It makes sense to have only one tool team (tool sharing, avoid reinvention). But then this team need to provide tools to several projects and it might delay the actual production of the tools, hence delaying the work of every team … leading to ad-hoc teams recreating themselves as it’s “impossible to get things done from those tools dev”. Ever seen that happen ? Is it sustainable in game dev world ?

Regards
PH

]]> By: Jay http://thetoolsmiths.org/2009/02/03/the-problem-with-ad-hoc-tools-teams/comment-page-1/#comment-348 Jay Wed, 04 Feb 2009 16:53:24 +0000 http://toolssig.wordpress.com/?p=79#comment-348 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). The best way for this to work is if the official tool team provide components that every developer can use. For instance there may be a GUI component you can use to build the interface for the tool easily without being an expert at UI design. In practice however I have seen many of the problems you described: duplicate functionality, no support, no documentation... 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).

The best way for this to work is if the official tool team provide components that every developer can use. For instance there may be a GUI component you can use to build the interface for the tool easily without being an expert at UI design.
In practice however I have seen many of the problems you described: duplicate functionality, no support, no documentation…

]]> By: Jeff Ward http://thetoolsmiths.org/2009/02/03/the-problem-with-ad-hoc-tools-teams/comment-page-1/#comment-347 Jeff Ward Wed, 04 Feb 2009 15:36:37 +0000 http://toolssig.wordpress.com/?p=79#comment-347 I'm advocating formalizing your tools team. You have one whether you believe it or not, but by not formalizing it, you're actually creating more problems for yourself than if you dedicated 2 to 3 programmers to only creating and supporting your tools. I’m advocating formalizing your tools team. You have one whether you believe it or not, but by not formalizing it, you’re actually creating more problems for yourself than if you dedicated 2 to 3 programmers to only creating and supporting your tools.

]]> By: PH TRIVIER http://thetoolsmiths.org/2009/02/03/the-problem-with-ad-hoc-tools-teams/comment-page-1/#comment-346 PH TRIVIER Wed, 04 Feb 2009 09:01:37 +0000 http://toolssig.wordpress.com/?p=79#comment-346 I might be missing something here ... are you advocating *not* building custom tools ? Or are you just talking about the kind of tools should should be able to buy off-the-sourceforge ? Or making clear that tools team should be making tools and nothing but tools, until tools are complete and usable and re-usable and re-saleable ? Cheers PH I might be missing something here … are you advocating *not* building custom tools ? Or are you just talking about the kind of tools should should be able to buy off-the-sourceforge ? Or making clear that tools team should be making tools and nothing but tools, until tools are complete and usable and re-usable and re-saleable ?

Cheers
PH

]]>