Programmer Musings

The Right Tool for the Job

I ran across an unusual article a couple of months ago, Ethical Software by Alex Bunardzic » Right Tool for the Job is a Myth. My first thought was that the author must be out of his mind. After some reflection, I have a somewhat different view. Now I just think he is mistaken. I would definitely suggest reading his article and the associated comments so that you understand his viewpoint. I wouldn't want to misquote anyone.

The author maintains that the phrase the right tool for the job is a meaningless statement because in the software world there are not as many choices as in the real world. Honestly, I don't know what to say about that. Most of my programming career has been spent narrowing an infinite number of possible solutions down to a few that might possibly work. Since I can't get even a basic grip on his general statement, let's look at some of the specific examples.

TCP/IP

For example, when implementing a software system that is going to be distributed across a network of computers, it is pretty darn impossible to choose the right tool for the job — because there is only one tool to use, and that tool is TCP/IP.

This statement can be easily refuted by pointing out that UDP is still in wide use on the Internet. Several distributed systems depend on this alternative to TCP, including DNS, VoIP, and TFTP. Obviously, there are multiple choices for the right tool in the area of distributing systems. Moreover, if you are working with small devices that do not support a TCP stack, you might end up using something completely different like the protocols from the ZigBee specification.

Each of these communications protocols has different strengths and weaknesses. Part of what makes programming interesting is the ability to look at these various choices and decide which advantages you want and which trade-offs you can live with. To a small extent, Bunardzic is partially right. More and more devices are getting TCP stacks, so it is becoming a viable option more often than it once was. But, that does not mean that it is the only choice.

Relational Databases

What choices of tools do we have at our disposal if we wish to implement a relational database? No choices. There is only one tool — SQL (Structured Query Language).

The comments pick this one apart pretty well. The main argument is that the question is narrowly defined to specify basically one answer. If we change the question to one that a developer is more likely to encounter: How do we store the data we need for our application?, the answer is less clear. If you only have a handful of key/value pairs, a property file or INI file is probably a better choice than a relational database. If you need to store gigabytes of of floating point information, raw binary files in a directory may be the best solution. For other problems, a CSV file might be exactly what you need.

In most of these situations, SQL would not be an option, because the data is not relational.

Business Logic

The last example solves the Business Logic problem with Object Oriented Programming. Although OOP is the current default programming paradigm, that does not mean that a rules-based expert system might not be a better solution in some domains. I've seen a number of environments where a pipeline of simple procedural pieces did as good and clean a job as any OO design. In many cases, these alternatives will not be best, but that does not mean that they do not exist.

Missing the Point

The worst problem with this article is that it misses the point of most of the right tool for the job comments I've seen over the years. At least in my experience, this suggestion was normally used when someone was really misusing technologies. Here are some examples of decisions that might generate this kind of comment:

• Using an RDBMS to store a set of a dozen key/value pairs for configuration.
• Using a CSV file to store information on a thousand employees.
• Using a SOAP message to send a yes or no response.
• Using a shared directory on a file server to coordinate a dozen machines in a distributed network.
• Using FORTRAN 77 for an application doing extensive text parsing.
• Attempting to write device drivers in Java.
• Using almost any programming language to pick 5 random names out of a list of 100, one time only.

In almost any application, there is the possibility that someone will choose a suboptimal technology. In many of those cases, it is just a matter of ignorance of the alternatives. Education and experience are the only solutions.

I'd like to close this with a quote from Larry Wall that captures the essence of this problem.

Doing linear scans over an associative array is like trying to club someone to death with a loaded Uzi.