Not too long ago someone asked me, how could I claim to be an Agile developer when Agile values “Individuals and interactions over processes and tools” and I talk about the tooling more than anything?

Firstly, I believe that developers discussing the right tooling IS individuals and interactions.

I think that this value statement is really criticising processes and tools as a substitute for individuals and interactions. The kind of blind reasoning “We’ll use this super-duper methodology and buy this hyped-up software and then hire some junior developers to get on with it all and not have to worry about whether we’re doing it right because with these processes and tools we can’t possibly go wrong.”

When the Agile Manifesto was written, Kent Beck added the important clarifying statement:

“That is, while there is value in the items on the right, we value the items on the left more.”

So clearly everyone recognises processes and tools are and always will be important.

In fact, selecting the best tools for the job is one of the most basic things that you can do in any profession.

Imagine you have very bad toothache and visit a dentist. You have checked that he has all of the certifications expected of such a professional so no reason to suspect that you won’t get a good level of service. He advises you that unfortunately the tooth has got so bad that it will need to be removed.

Now he hands you a bottle of absinthe, tells you to take drink as much as you want, and also pulls out a pair of pliers. You jump out out your seat and ask him what he hell is he thinking? He assures you that he has used these tools in the past on other patients and found that they “work”. Would you pay for this kind of service? Do you think that he can call himself a professional?

Unfortunately the software industry is not yet as mature as many other professions. This is why we still see basic amateur tools, that are known to “work”, being used instead of best of breed tooling.

In assessing a tool for a job, you must consider several things:

• The appropriateness of the tool for delivering the immediate requirements
• The appropriateness of the tool for delivering any requirements that are likely to emerge in the future 
• How much that tool ties you in.

If it is a small open source JavaScript framework, it may be easy to swap it for another one later on, or enhance the framework yourself. If you are selecting a closed source platform for your software, it is likely that the team will be very much tied in. So before you choose it, be sure that you know it is the right tool for the job.