Use the right tools for the job

As the tools we use become increasingly more powerful and extendable, with it comes the temptation to over exploit their functionality. This isn’t always a bad thing, but sometimes we get lured into using tools for purposes in which they were never intended. This can have adverse effects in the long term. Let’s look at those in turn:

As hard as we try, oftentimes we cant avoid having to use certain tools. Whether its because we don’t have the time or skills to build our own; sometimes we just have to buy. My first suggestion is whenever you adopt a new tool you should always think about an exit strategy. I’ve seen companies stuck in bed with vendors who’s license costs rise exponentially on an annual basis, and they find themselves debating whether they should use their £million maintenance money to move off a tool/platform. Mainframe anyone?? Don’t let a tactical decision end up as your strategic solution!

When you leverage a tool for functionality outside of the norm, you run the risk of those features being removed at any time. I once had a scenario where some colleagues had extended Jenkins to create a web form which would post rest calls to another back-end system. They did this through the use of a plugin that had a fairly small community for support. The problem here is when we needed to upgrade Jenkins to get the latest patch fix, this plugin was still lagging behind and had broken with the upgrade. In this instance a simple X on rails framework would have done the job and broken any dependencies on Jenkins.

Increasing tool load. Lets go back to the Jenkins example above. If we have thousands of people filling in this web form and submitting to backend systems, then we are placing additional load on Jenkins. Fact. Jenkins is a build system, and can often be fairly critical to delivery. If we’re placing unplanned load on the service and bring it down, then we run the risk of hindering other users who may choose to use the tool also.