Comments on: Tools Team Test – 5 steps to better tools Another thing I would add to the list, is the tools should fit the workflow of the user. At one of the places I worked, initially we were just making tools that fit what we thought the user should be doing. We never actually talked to the end user. Not surprisingly while the tools satisfied all the conditions in this article (i.e. we had very nice documentation etc), the end user never actually used the product. We made a paradigm shift about half way through my time there, and instead of just blindly guessing what the user wanted we started actually talking to them. So we started actually doing analysis/design with our user group, often getting a few key people from the team, and we'd actually make prototypes with paper/white-boards and get the user to simulate their workflow. Things about their workflow that aren't obvious to the programmer suddenly became obvious. A right click here, drag drop there and the tool for the end user becomes a lot more pleasant without much additional programming.Also sometimes the programmer can be totally off on a tangent that just doesn't fit the end users workflow at all. An example is a sound mixing tool I made. The initial version I took the brief from one of the engine programmers who had a very clear vision of what he wanted. Diagram based mixers, where the user would draw the line between the different mixers to simulate a signal connection. The problem is sound engineers don't even think that way. I had a fully working prototype, even showed the sound guys a few samples thinking everything was going along fantastically. Got the tool tests/documented up and then no sound engineers were using it. Turns out what they really want is a simulation of a real world mixing desk. Where they have mixing units, dsp units. Sitting down with the guys, doing mock prototypes suddenly we started getting a product that they'd actually use. Since by that time I had already taken the tools team across to windowing frameworks such as WPF it was much easier to get the visual rich controls that they required. Not listening to the user requirements is a problem with many programmers not just those in the gaming world. Another thing I would add to the list, is the tools should fit the workflow of the user. At one of the places I worked, initially we were just making tools that fit what we thought the user should be doing. We never actually talked to the end user. Not surprisingly while the tools satisfied all the conditions in this article (i.e. we had very nice documentation etc), the end user never actually used the product. We made a paradigm shift about half way through my time there, and instead of just blindly guessing what the user wanted we started actually talking to them. So we started actually doing analysis/design with our user group, often getting a few key people from the team, and we’d actually make prototypes with paper/white-boards and get the user to simulate their workflow. Things about their workflow that aren’t obvious to the programmer suddenly became obvious. A right click here, drag drop there and the tool for the end user becomes a lot more pleasant without much additional programming.Also sometimes the programmer can be totally off on a tangent that just doesn’t fit the end users workflow at all. An example is a sound mixing tool I made. The initial version I took the brief from one of the engine programmers who had a very clear vision of what he wanted. Diagram based mixers, where the user would draw the line between the different mixers to simulate a signal connection. The problem is sound engineers don’t even think that way. I had a fully working prototype, even showed the sound guys a few samples thinking everything was going along fantastically. Got the tool tests/documented up and then no sound engineers were using it. Turns out what they really want is a simulation of a real world mixing desk. Where they have mixing units, dsp units. Sitting down with the guys, doing mock prototypes suddenly we started getting a product that they’d actually use. Since by that time I had already taken the tools team across to windowing frameworks such as WPF it was much easier to get the visual rich controls that they required. Not listening to the user requirements is a problem with many programmers not just those in the gaming world.

]]>
By: Glenn Watson/2011/01/20/tools-team-test-5-steps-to-better-tools/#comment-629 Glenn Watson Tue, 25 Jan 2011 02:49:13 +0000 I'm not sure that using SCM to deliver tools is a bad thing as long as it's managed the right way. Where I currently working we have an automated tool which is designed to sync local branches with the protected mainline which, among other things, sinks the tools binaries as well. So, with this system running whenever the tools team publishes a change from their branch into mainline by the next morning everyone will have caught up and be using that version.The one other thing I will say is that while the dedicated tools team might be able to handle 99.9% of the work sometimes you just 'need' to do something yourself. A specific example from before Xmas was my need to reformat/package some data midway through the existing export pipeline. Now, while I could have spoken with the tools team and had them do the changes I took it upon myself to write an extra C# DLL and C++ external program to perform the operation and, given the fast iteration on the changes it was a good job I did; as I recall I made large changes on the data layout twice in one day once in order to optimise the data based on testing.I guess what I'm saying is that while a Tools Team is great to have and I'd hate to work on a project without one in the future, sometimes you just need to get your hands dirty and do things on your own but even then work WITH the Tools Team as they will thank you if you need to monkey with their pipeline ;) I’m not sure that using SCM to deliver tools is a bad thing as long as it’s managed the right way. Where I currently working we have an automated tool which is designed to sync local branches with the protected mainline which, among other things, sinks the tools binaries as well. So, with this system running whenever the tools team publishes a change from their branch into mainline by the next morning everyone will have caught up and be using that version.The one other thing I will say is that while the dedicated tools team might be able to handle 99.9% of the work sometimes you just ‘need’ to do something yourself. A specific example from before Xmas was my need to reformat/package some data midway through the existing export pipeline. Now, while I could have spoken with the tools team and had them do the changes I took it upon myself to write an extra C# DLL and C++ external program to perform the operation and, given the fast iteration on the changes it was a good job I did; as I recall I made large changes on the data layout twice in one day once in order to optimise the data based on testing.I guess what I’m saying is that while a Tools Team is great to have and I’d hate to work on a project without one in the future, sometimes you just need to get your hands dirty and do things on your own but even then work WITH the Tools Team as they will thank you if you need to monkey with their pipeline ;)

]]>
By: bobvodka/2011/01/20/tools-team-test-5-steps-to-better-tools/#comment-628 bobvodka Sat, 22 Jan 2011 14:49:02 +0000 @rgba32 Correct! "Dedication is what you need" 10 Points! @rgba32 Correct! “Dedication is what you need” 10 Points!

]]>
By: rgba32/2011/01/20/tools-team-test-5-steps-to-better-tools/#comment-625 rgba32 Thu, 20 Jan 2011 20:43:28 +0000 What kind of build server have you used? Did you have special needs. For example, We use Hudson with a main server under windows and slaves under linux and osx. Deploying a new slaves takes only minutes. And project are tested on all relevant platforms Curious about your experience What kind of build server have you used? Did you have special needs. For example, We use Hudson with a main server under windows and slaves under linux and osx. Deploying a new slaves takes only minutes. And project are tested on all relevant platforms Curious about your experience

]]>
By: Joe Valenzuela/2011/01/20/tools-team-test-5-steps-to-better-tools/#comment-623 Joe Valenzuela Thu, 20 Jan 2011 17:36:13 +0000 I would add: 7 - You use as much existing library as possible.While working on Totems (10Tacle ), the CEO decided not to use an existing build server solutions. He assigned 2 programmer on this task for several month. The result was nothing compared to existing free tools. At Fishing Cactus, we're targeting a bunch of platforms. And we need to work on 3 different host OSes. So we decided to use ant, ivy and hudson as support for our tools. I would add: 7 – You use as much existing library as possible.While working on Totems (10Tacle ), the CEO decided not to use an existing build server solutions. He assigned 2 programmer on this task for several month. The result was nothing compared to existing free tools. At Fishing Cactus, we're targeting a bunch of platforms. And we need to work on 3 different host OSes. So we decided to use ant, ivy and hudson as support for our tools.

]]>
By: David Evans/2011/01/20/tools-team-test-5-steps-to-better-tools/#comment-621 David Evans Thu, 20 Jan 2011 16:43:40 +0000 I have a little additional recommendation: be sure to backup your tools source code, in SCM or anywhere, even one-time hacks.Silly? Probably, but I have already been struck twice by this. An artist asks you for help on a very small and specific task, you quickly hack together some minimalistic tool with a window and two buttons and the artist is happy, then you completely forget about it. A year later the artist comes back and tells you "remember that tool you gave me? now the whole team is using it daily but the latest data format change broke it, could you update it?" and you suddenly realize you have no idea where that quick hack went... Really, things like this happen. I have a little additional recommendation: be sure to backup your tools source code, in SCM or anywhere, even one-time hacks.Silly? Probably, but I have already been struck twice by this. An artist asks you for help on a very small and specific task, you quickly hack together some minimalistic tool with a window and two buttons and the artist is happy, then you completely forget about it. A year later the artist comes back and tells you “remember that tool you gave me? now the whole team is using it daily but the latest data format change broke it, could you update it?” and you suddenly realize you have no idea where that quick hack went… Really, things like this happen.

]]>
By: Justin Liew/2011/01/20/tools-team-test-5-steps-to-better-tools/#comment-619 Justin Liew Wed, 19 Jan 2011 23:00:02 +0000