My Love/Hate Relationship with Dev and Test Tools
I love tools, particularly those that I buy at home improvement stores. I have a wide variety in my shop; most I've used, but others I bought because they just looked or sounded cool, or I thought I'd need them someday. Most of us have toys to play with; mine are tools, both manual and automated.
However, when it comes to development and test tools, I'm much more discerning. Having made my fair share of tool-investment decisions that yielded little or even negative return, my "learning experiences" have reinforced the old saying—"A fool with a tool is still a fool." Whether homegrown, open source, or commercial off-the-shelf tools, all of them tend to entice the unsuspecting user with a promise to solve nearly any development or testing challenge one will encounter.
Now of course we all know better, but still, the anticipation, hope, and dream of one day letting the computer do all the work is extremely attractive. Having celebrated both successful tool implementations and failed tool deployments, I have learned some things and suggest you keep these in mind as you reach for that next cool tool.
- Define your requirements: Have a set of well-defined needs for the tool you are considering. Whether shopping for a requirements tool, an integrated development environment, a coverage tool, or a unit or functional test tool, if you've not defined your needs up front, then whatever the tool does will most likely drive your decision—or worse yet, the vendor will tell you what you need.
- Have a longer-term plan: Rarely will a couple of tools meet all of your needs, so planning, architecting, and designing which tools you need across your software development lifecycle and how those tools will integrate with one another are critical. We need an overall architecture and implementation plan for our tools.
- Implement incrementally: Attempting to purchase a large number of licenses to deploy across multiple teams rarely works. We must allow time for adoption and refinement. Don't forget that you will need to adapt your methodology to the tool and vice versa. It takes time to work out all the details.
- Avoid one size fits all: Some tool providers strive to put mega functionality into one tool such that the feature set spans the entire lifecycle. This usually results in a tool that only has mediocre capabilities. A more specialized set of tools that integrate together is often more beneficial.
- Measure contribution: A "free" tool is not free. You will spend time adapting the tool to your environment, training people, and maintaining the tool. This investment must be tracked and then compared against the benefit that the tool is yielding for the team.
Now, if I could only apply this guidance to my home shop tool collection, I'd have far less "shelfware."
