Kevin Eaton, PhD

Technology Leader, Non-Profit Founder, PhD, Chaplain, Geek

Wrong Tool for the Wrong Job

3 minutes
July 21, 2015

I am happily employed. This has not always been the case. Here, I share a few stories and anecdotes, both from me and from several of my peers.

In order to move quickly and flexibly, developers need to be happy and have the right tools. The right tools can enable developers to do amazing things, while the wrong tools can hinder motivation, efficiency, and agility. What the “right” tools are depends on the job.

I asked some of my peers for examples of “wrong tools” for the job. Here are some replies:

Take source control, for instance. The Gold Standard for modern development is git. Subversion used to be the de facto (and some people may argue it still is). The fact is, either tool can be great if used effectively.

I had the unfortunate experience of having to work with AccuRev instead of git at a contracting position. Think of AccuRev as everything git shouldn’t be hidden behind a clunky, difficult interface. Whereas “git status” will show you your modified and excluded files, in AccuRev it is not so easy. They also changed the vernacular commonly used (“streams” instead of “branches”, “promote” instead of “commit” or “push”, “workspace” instead of “checkout”). The UI is slow and, most importantly, you get the privilege of paying for the ability to use such poor software.

Let’s take Operating Systems. I love Windows, Linux (Mint is my preferred, but Elementary is a nice UI as well), and Windows. When doing web development, it is hard to argue against a Linux or Linux-like environment, although Windows can be configured to support web development. However, many of my favorite tools aren’t available in Windows. One position I was involved in mandated “Windows 7 from our IT department with no unapproved software.” You know what wasn’t on that “approved software list”? Most of the tools I would like to use: Sublime, VirtualBox, Docker, git, and countless others. Why can’t a developer use OSX or Linux, especially if they are not asking someone else to support it?

Or how about restricting work hours and locations? At “yet another” position, all work had to be done on their “blessed” machines using their tools and only could be done while connected to a horribly slow VPN. All project management, source control, and documentation was behind the VPN. This wouldn’t be a big deal if the VPN was not painfully slow (I have a pretty fast connection that allows me to stream and torrent ISOs pretty quickly, but I would be lucky to get 100k down over the VPN).

At the end of the day, developers are expensive, both to hire and to maintain. However, they can also be the lifeblood of an organization. Give them the tools they need, allow them to stay flexible, use the best and most appropriate technologies, and keep them motivated. To not do so drains resources and wastes time.