Uncharted Waters

Sep 29 2016   4:41PM GMT

How I Pick Development Tools

Justin Rohrman Justin Rohrman Profile: Justin Rohrman

Development tools

I spend a lot of time at community events every year. At every event, without fail, people want to talk about tools. The development community in particular seems to have a sever case of tool fetishism. At the testing events I participate in, people usually want to know what the best tool for X is. X might be front end testing, back end work, ETL testing, security, or whatever. This is a hard question to answer. I will rarely have enough information about the product they are working on, what the teams skill set it, and what problems they are trying to solve to give a reasonable answer. That, and I don’t really believe in the concept of best, anyway.

I do think there is something close to good enough for us right now. I want to talk a little about how I pick development tools, and why I do it this way.

What’s Your Problem?

The first time I was part of a tooling discussion was in 2006. The company I was working for was having a problem with regression testing taking too long. We were releasing software a little less than quarterly at that point, and pre-release testing usually took two or more weeks. The VP of development had seen someone in ops using a tool called AutoIT to automate small tasks and decided that would be perfect for us.

I spent a few days getting familiar with the tool and building a proof of concept. I ran a demo to the development directors and the VP that selected the tool and nearly every test failed because the screen resolution was different on that computer and the scripts couldn’t find objects on the page. The UI testing tools are of course more sophisticated now, they can locate UI elements several different ways, but that sort of testing wasn’t going to help us much anyway.

development tools

The problem we were having was that we were trying to release too much software at a time and developers were making a lot of bugs that was causing the team to get stuck in a find, fix, retest loop. No manner of UI testing tool was going to solve that problem. Releasing software in smaller pieces (to reduce risk) and testing more at lower levels like the unit and API would have helped. We were given an edict to go with the UI testing approach and off we went.

Overcoming Objections

Technical staff selecting tooling are being put in a position they usually don’t have any experience with, sales. Everything cost money some how. Commercial tools will have licensing and support fees, open source tooling will more often than not cost time. Managers tend to think of things in terms of where they fit in the yearly budget. They have a limited amount of money to spend. Some of that goes to staffing, some of that goes to administrative cost, and some to a technology budget for things like tools.

For me, they key to overcoming objections was to avoid the conversation all together. Whenever possible, I would download and use tools when I wanted to solve problems as I discovered them. One time, that was a javascript framework so I could test an API, another time it was a Windows utility that could synchronize files between directories. Objections only happen when management thinks they have more expertise than you do, or you are asking to spend money. Sometimes the decision makers do have expertise in development, but today it is pretty easy to avoid spending money on tooling.

Some of you might work in companies that lock down development computers and require admin permission for any install. Unfortunately, I can’t give you any advice except to suggest there are other companies out there that don’t restrict their employees to that degree. Picking development tooling is hard, but I always get better results when I start by figuring out what problem I’m trying to solve. There is no ‘best’, and if someone tells you otherwise, they are selling something.

 Comment on this Post

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

Share this item with your network: