The Right Tool for the Right Job

I've been working in IT now for a good many years and as my job is done on entirely different client sites I've seen a wide range of working practices, both on the IT and the business fronts.

One common theme unites all my experiences in annoyance, the 'One Tool Wonder'. Virtually everywhere I go I encounter someone who once had success using a tool or technique and insist on applying it everywhere.

It's a lot like the fellow who was really happy with how much better a hammer was for knocking nails in than the heel of his shoe, he now spends all his day working out how to use a hammer in all his home improvement problems. Don't scoff, I once spent a very interesting afternoon watching someone put up fence panels, hammering the screws into place. I looked at the fence only a couple of months ago and the wood around the screws is beginning to rot beautifully, mangled as it is by the forceful passage of the screw.

One of my perpetual mantras is now 'The right tool for the right job.', whenever I am doing something I try to use the best tool for that piece of work. A lot of good tools are supplied on site or by the OS that is in use. but I also have tools that travel with me.

• IntelliJ - Possibly the best java editor bar none.
• Ultraedit - My personal poison when it comes to text editors.
• Ant - The most flexible build tool available, partly this is due to my knowledge of this tool, but also I feel that tools such as Maven only suit a sub-set of projects. I will use Maven where appropriate, but...
• Castor/JAXB - I tend to use one of these two, depending on the Java/XML binding capabilities required.
• Middlegen/XDoclet - EJBs do have a ridiculous quantity of boilerplate, I find that the combination of these tools make life a lot easier.
• DBVisualiser - There are various fantastic database specific tools, but as most of my work is in Java, I tend to favour a tool that works with the JDBC drivers that I will be using so I can check out issues independent of my code.

I am always ready to substitute tools with one that is more appropriate for the particular job, but generally these are my preferences.

In my life outside of work, I apply this mantra too. I have a garage of tools for my classic car and for overclocking and my kitchen is well stocked with the correct utensils.

In many ways the most abused tool in the developer's toolbox is XML and it's associated technologies. Here are a few examples of abuse.

• Storage of simple key-value pairs, that is what a properties file is for. Properties files are expressly designed for this form of data, are simple to maintain, easy to grasp and are fast. Admittedly there is the converse scenario where the properties file has complex keys and data and really might be better in another form such as XML.
• 500k or larger XML configuration files, where most developer time is taken up with these files as the configuration has become so complex that the XML dialect is a programming language itself. This is where a known scripting language or the base language itself should be considered. You've hired Java developers, yet they spend 95% of their time editing your pig-awful configuration file structure. Sorry, brief flashback there.
• Overuse of XSLT. It is a wonderful tool, but a few rules of usage need to be established. The core premise of XSLT is converting one data-complete XML format to another. The further you move away from that, the less appropriate it is. Also, while XSLT is sufficient for writing a ray-tracing engine, I really wouldn't recommend it.

I really could carry on ranting from here on in, but the best thing for me to do is stop and just plead with you to really think about the right tool for the job.

Just because you can see how to solve a problem with a particular tool doesn't mean that it is the best tool or will solve the problem in the best way. Always spend time learning and looking at new tools so that your toolkit has the best chance of solving problems well.