Tools Come at a Cost

One of the experiences I share with a lot of people in this modern world is that I forget phone numbers. I never used to. The problem is that my mobile phone remembers them for me. So, phone numbers no longer stick in my own head. If I want to call a colleague, I first look for my phone. If I can’t find my phone, I don’t make the call.

Another way of looking at this is that my life has been simplified in some ways by my mobile phone, and in some ways it has been made more complicated. I would argue that it was simpler for me when I was forced to memorize phone numbers. It was simpler in that my use of many useful phone numbers was completely independent of external equipment.

Any tool that helps me, also costs something. Any tool, agent, or organization that abstracts away a detail may also takes away a resource that I might sometimes need, and may atrophy if not used on a regular basis.

Test Tools Come at a Cost– Even if They are Free
This weekend, I attended the 5th Austin Workshop on Test Automation. This is a group of “test automation” people who are sharing information about test tools– specifically, open source test tools. It’s wonderful. I’m learning a lot about free stuff that might help me.

But I notice a pattern that concerns me: an apparent assumption by some of my helpful tool developer friends that a tool of theirs that handles something for me (so that I don’t have to do it myself) is obviously better than not having that tool.

So, let’s consider what is offered when someone offers me a tool that solves a problem that crops up in the course of doing a task:

• Some capability I may not already have.
• Possibly a new set of abstractions that help me think better about my task.
• Possibly a higher standard of “good enough” quality in my task that I can attain because of the new capability and abstractions.

But what is also offered is this:

• Problems in that tool.
• New problems due to how the tool changes my task.
• New problems due to how the tool interacts with my technological or social environment.
• One more thing to install on all the platforms I use.
• The necessity of paying the operating costs of the tool to the extent I choose to use it.
• The necessity investing time to learn the tool if I choose to use it (and to keep up with that learning).
• The necessity of investing effort in using the tool (creating tool specific artifacts, for instance) that might not pay off as well as an alternative.
• Having invested effort, the possibility of losing that investment when the tool becomes obsolete.
• Avoidance of the learning and mastery of details that I might get by solving the problem myself.
• A relationship with one more thing over which I have limited influence; and a potentially weaker relationship with something else that I know today.
• Possible dependence on the owner of the tool to keep it current.
• Possible legal entanglements from using the tool.
• A sense of obligation to the provider of the tool.

I find it useful to explore tools. I want to learn enough to hold in my mind a useful index of possible solutions. And of course, I use many test tools, small and large. But I’m wary of claims that a new tool will make my life simpler. I appreciate a certain simplicity in the complexity of my world.

— James