Only tools use too many tools
June 13, 2011 - 0 Comments - tools
One thing I’ve found that most engineers dislike is the overuse of tools. I’m not talking about build tools or other command line tools, which automate repetitive tasks and make our lives easier. I’m talking about the tools that management wants everyone to use, whether it be for bug tracking, feature reviews, project management, or any other work that is peripheral to the actual task of writing software.
These tools aren’t inherently bad. They can be of great assistance to the process of deploying quality, production-ready code. But I’ve encountered the situation more than a few times where these tools have done more to get in the way than they have to actually help. Usually it’s either due to not picking a tool and sticking with it, or to using tools where they aren’t necessary.
Exhibit A: Too many tools
Here’s one scenario from real life. One company I worked at used five different tools for tracking progress. Five. Two is one too many, and they had five. Trac, Pivotal Tracker, Basecamp, and a couple others whose names I don’t even remember, all played into some sort of chaotic dance to which nobody in the company knew the steps. Every project had its own tool for tracking bugs and progress. Nobody knew which tool to go to for updates. It was a mess.
They eventually moved to a convoluted, over-engineered JIRA setup, but I won’t get into that.
Exhibit B: Redundant, low-quality tools
Here’s another scenario. A company is using GitHub to manage its code repositories. Great! GitHub has a lot built-in, much of which can be put to good use by companies of many sizes. But this same company is also using a completely separate tool, Review Board, to do code reviews. Using this tool involves the complicated process of running a special script for rebasing and diffing your feature branch, which can break for many reasons and leave your local repo in a weird state. Even if you do succeed in generating the correct diff, you have to then manually upload it to the Review Board software.
Why go through that trouble? GitHub has Pull Requests built-in and has for a long time. They provide a diff of your branch as well as a discussion thread for that diff. You can track changes as you go, and when it’s ready, just click a button to ship it. What more do you need?
Exhibit C: The right approach
One last thing. Many of these tools are more to help managers do their jobs than engineers themselves. To that end, I think it’s a good policy to limit engineers’ exposure to such tools as much as possible. Let them spend their time writing software.
Another company I worked with had a great approach; engineers were not expected to update Trac at all. Each team would have a sprint meeting with the relevant managers at the beginning of each week, where each ticket would be addressed via projector and the manager running the meeting would take care of interfacing with Trac. It was a marvelous approach. We engineers could focus on writing code and the managers could focus on tracking progress. The way it’s supposed to be.
Conclusion? Choose your tools wisely. Don’t use tools redundantly.
