Advertisements
Posted by: jsonmez | December 3, 2009

Dedicated Developer Tools Teams

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 anyone with a dedicated developer tools team.  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

  1. Write a unit test
  2. Write a rule to try and make the whole unit test pass
  3. Build the rules package (7 minutes)
  4. Run your unit test which causes the rules to be reloaded to disk (2 minutes)
  5. Find out it didn’t work, and change the unit test
  6. Modify the rule
  7. Build the rules package again (7 minutes)
  8. Repeat 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 you unit test, just like it was pure java code.  Thus the process changed to

  1. Write a unit test
  2. Write part of a rule to try and make it pass
  3. Run the unit test which automatically loads your changes for just that rule (5 sec)
  4. Done, move onto the next unit test (your 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 6*30*90 = 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 doing this already?

Advertisements

Responses

  1. […] it would make sense to have a team dedicated to architecture.  This team is also a good one to be creating developer tools.  I have actually been part of a team doing this kind of role, and I think it worked out pretty […]

  2. […] shouldn’t we automate software development?  I’ve written about this topic before, saying every project should have a dedicated developer’s tools team.  I’ll probably write about this topic again, it is that important. We spend a large amount […]

  3. […] to Automate Okay, so you’re convinced you need a developer tools team, or at least that development tools are important to […]

  4. […] is a problem with the tooling you have created to support your application.  You might consider creating some development tools that will allow you to simulate any production issue in a different environment without having to […]

  5. […] the Sawhorse I love talking about tools and automating.  I’ve written about having a dedicated developer tools team, and what you should […]


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Categories

%d bloggers like this: