Every large team needs a developer tools team
I have been realizing more and more the need for developer tools and setting aside dedicated time to create them. I've noticed many organizations have internal tools teams, but I haven't seen dedicated developer tools teams. I am sure there are some out there, but I just haven't seen them yet. I am pretty convinced that any decent sized project needs to have a dedicated team for building tools to be used by developers.
What do I mean by developer tools?
I don't mean defect tracking systems, or test case management system, or internal workflow websites, etc. Let me give you an example. On the project I am currently working on we use a particular rules engine software called ILOG. When I was working on the architecture team and not actually writing rules and trying to unit test the rules, I didn't realize how inefficient the whole process was. I ended up becoming the Scrum Master of one of the teams using this software package and immediately felt the pain of:
- Writing a unit test
- Writing a rule to try and make the whole unit test pass
- Building the rules package (7 minutes)
- Running your unit test which causes the rules to be reloaded to disk (2 minutes)
- Finding out it didn't work, and changing the unit test
- Modifying the rule
- Building the rules package again (7 minutes)
- Repeating until rule works correctly
The very first thing I did was create a “Rule Loader” that could load just one rule without having to build the entire package, and allowed you to make a change against a rule and instantly run your unit test, just like it was pure java code. Thus, the process changed to:
- Write a unit test
- Write part of a rule to try and make it pass
- Run the unit test which automatically loads your changes for just that rule (5 sec)
- Done, move onto the next unit test (you're done instead of going back, because you wrote a small unit test instead of a large one because you can load the rule much faster now)
Thus a developer tool was born. We later found the same problem with functional testing and added a hidden webpage to trigger the rule loader to load up rules dynamically while the application was running, which saved even more time.
Developer tools are tools which speed up development.
There are many examples of developer tools. The only way you can figure out what developer tools are useful is to have a developer customer. You either have to have a developer build the tool or ask them. Once I got down in the trenches I was able to immediately see the need for several tools, which I then developed which saved countless hours across the entire project.
Who builds developer tools?
I stress the point that this is not the same as an internal tools team. They are usually building tools for the customer that is the internal business or even development workflow. Developer tools are focused at developer customers. Consider some of the meta-developer tools just as ReSharper. Those are general to development, but developer tools on a project would be specific to development on that project. I would recommend having a dedicated team that has their own iterations that build developer tools from developer stories. Now this isn't always possible due to the size of projects, team and budgets. In that case, and perhaps a better solution is to take one developer from each team each iteration and put them on a special developer tools team for that iteration. In this way, you will get developers from the trenches building their own tools and “eating their own dog food.”
Why?
When we do things over and over again it is a waste of time when we could automate some of the steps. When you work on a large team the amount of wasted time multiplies. For example, if you can build a tool that saves a developer 2 minutes of work each time they work on an item of work, and they work on 3 items of work a day on average. You are only saving 6 minutes a day. Not a huge savings, but when you multiply that times 30 developers, and you multiple that over the number of days in a 90 day project you get 63090 = 16,200 minutes. That is 270 hours. Can you spend 70 hours to build a tool that will save 2 minutes off most of your development tasks? In that case you net 200 hours of productivity in 90 working days? So why doesn't everyone already do this? Simple: a developer isn't concerned about saving 6 minutes a day. In general a developer with a deadline trying to complete work is not going to see the bigger picture of investment of a large number of hours to save themselves 6 minutes a day.
Agree? Disagree? Anyone already have a developer tools team?