The “Best Tools” Dilemma

A popular phrase in the software industry is “using the best tools for the job.” That sounds really great. It makes software developers seem on-top of things, wise beyond their years. After all, why would you NOT use the best tool for the job? Why would you use the worst tools for the job? That would just be foolish.  To be honest, this is kind of a buzzword phrase that developers use to try and end a discussion or argument. In my almost 15 years of professional development, I have never heard anyone argue with this statement.

What is the Best Tool?

However, there are a couple problems with this statement (and also, with the mentality). First of all, it is incredibly vague. It can be used at the start of a project, when people are discussing how to start a project. Someone will say, “We should use the best tools for the job.” Everyone will nod their head, verbally agree, and have a feeling of relief, because finally, a project is going to be done right.  But what really got established there? Absolutely nothing. There was no discussion of what IS the best tool for the job, only that the best tool will be used. There was also no discussion in what constitutes best tool.

What if the best tool for the job is on a different platform? How likely is it that you’ll convince the people in charge of money that you need to scrap all your servers, because they won’t run the OS that you need for the very best tool? Most companies that’s not very likely.  So we’re willing to put constraints on it, and that’s not bad. It might not make sense for the scope of work to have a team learn a brand new language, especially if it’s only slightly better than the one you’re on.

The problem here isn’t the assumptions or constraints. The problem is that the assumptions and constraints rarely, if ever, get spelled out. In a room with 3 or 4 senior developers, there are 3 or 4 ideas of what the best tool for the job is, and what constraints there are.

How is the Best Tool Determined?

The next issue with the “Best tools for the job” mantra is how are those tools determined? This is different that assumptions and constraints above. Let’s imagine for a minute that everyone is very vocal about the assumptions and constraints. The new project absolutely cannot buy new hardware. It will have to run on the existing servers. Instead, the focus here is on tool evaluation.

The phrase “use the best tool for the job” is a corollary of another common phrase “If all you have is a hammer, every problem is a nail.” Personally, when I hear this phrase, I often think of someone trying to hammer in a screw. In fact, that’s been the follow up example that people use probably 7 out of 10 times. But I’m not sure that’s the best example. When I was in my mid-20s, I played around a little bit with woodworking. It was a fun hobby, but I’m kind of a cheapskate, that meant more often than not, I’d try to make do with what I had. I won’t go into all the details here, because it’s a software blog, not a woodworking blog, but there are saws that all perform the same basic function (cutting a straight line) but have vastly different approaches.  By the time I stopped woodworking, I had a circular saw, table saw and compound miter saw.  Each of these 3 saws could cut a piece of wood square, they could also cut at an angle. But they each had their advantages. The compound saw is sometimes called a chop saw, because it comes down from above. Before I had this, if I had a piece that was a bit too thick for my circular saw I’d have to cut one side, flip it over and cut the other side, and hope that the cuts met in the same spot. It was very frustrating. Then I got a chop saw, and cutting thicker pieces was now a breeze.

How does this relate to software development? It is not enough to say “this should be a single page app.” Even if that’s true, it’s completely insufficient. There are numerous client side MV* frameworks. Should it use Backbone, Angular, Knockout, Ember? What about the back end, should it use Spring, WebAPI, Sinatra?  Just as it’s not enough to say “I need a saw to cut this piece of wood” it’s not enough to say “I need a client side MV* framework.”

This is where I think analysis ends up falling short the majority of the time in software development. We consistently say we should use the best tool for the job, but most people don’t have a structure in place to evaluate the options. In order to have a shot at knowing what the best tool is, developers have to be exposed to a lot of tools. The time to do comparative analysis on what the database technology should be, is not in the midst of the project.  That’s when the decision should be made, but a developer needs to have already done the analysis. What is a use case for using a NoSQL database? What’s the case for an RDMBS? What things can an RDBMs uniquely solve and how do you know if your project has that case? The same can be said for front end technology. Single Page Apps are all the rage these days, all the cool kids are doing them. But what makes a SPA a good approach? Are there times when using a more traditional approach such as Java’s Spring or ASP.Net’s MVC makes more sense?  These are not questions that can be asked and answered when you’re starting a project.  They have to be issues you’ve wrestled with in the past, and now have experiential knowledge to share.

The sad state of affairs is that most people are completely uphold the statement “we should use the best tools for the job.” They simply haven’t used and experimented with other languages and frameworks than the one they are most proficient in. They can’t express their thoughts on why they like Zend Framework better than Bootstrap, or why they don’t like Knockout’s observables. They can tell you that they’ve always used Bootstrap, Angular and WebAPI, with SQL Server as the back end. And to them, that’s the “best tool for the job.”

In the end, the phrase “Best tool for the job” loses almost all value and it quickly devolves into meaning “The tools I’m most familiar with.”