This is my tool. There are many others like it, but this one is mine. My tool is my best friend. It is my life

With apologies to Stanley Kubrick, I can’t think of a better phrase to describe engineers and software companies. The focus is not on the what, the why or the how but on the tools. A colleague from Object Mentor once said, “Never make fun of a man’s tools”. It was hysterical, but revealing.

To explain, I use this analogy. A contractor shows up to remove a concrete / brick wall from your back yard. He is armed with a ball peen hammer. Naturally, you ask, “Did you bring other equipment? That is a pretty sturdy and large wall.” 

The contractor replies, “I love this hammer. Yesterday, I was finishing a piece of furniture and this hammer was perfect. Left the smallest indentation that i took out with a piece of 1000 grit sand paper. I love this hammer, it is all I will ever use. 

My response, as my mother would say, “Don’t let the door hit you in the ass as you leave”.

Let’s explore the causes, consequences and remedies of this developer malady. 

Before I continue, I will probably offend people by mentioning their particular type of hammer. It is not that I mean to offend, but the offense kind of proves my point.

I am not recommending any framework for any situation, but advocating that these frameworks should be in your tool box. This includes libraries, languages, frameworks, patterns. I am ambivalent to which one is used but view it as an optimization problem. Or to quote my father (in his Italian accent), “Oh shiiite Carmine, use de right tool for de right job.”

That begs the question: “What is the right tool?

The Right Tool
The approach I have found most effective in my career is to be language, technology, tool ambivalent. That is I look at the tools available and pick the ones most effective for the job. The decision has to be zero cost which I will get to next.

I look for the most performant, simplest APIs and tools. I am very aware that every API, language, etc. I add increases complexity. A dried eye evaluation must be made to determine if the complexity is worth it. Again, I am assuming that switching out technologies is near zero cost (next chapter).

I have a few other rules. If the API has security holes back of the line. If the API’s documentation has errors, it is a no go. Finally if the API requires complex dependencies (every imported library is overhead and may contain security errors) or special build steps that is an extraordinary high cost.

If you approach the decision without sticking to your hammer, the cost benefits can be fairly clear

Zero Cost Switch
I can’t tell you how many hours I have spent in meetings where ‘architects’ argue about which framework we should use without any provable evidence how it would work in the current application. I would replace the word ‘spent’ with ‘wasted’ if I did not learn early on to bring my laptop to actually do work.

Thing is, without application and tests, it is impossible to determine the fit of any library. You have to integrate the API and see if it works. These meetings are trying to find an unknown bound to an unknown and unless you have a laptop to actually accomplish anything are a waste of time.

This is where my term “Zero Cost of Switch” comes into play. No used APIs should bleed into your business layer. Doing so will cause swapping out APIs nearly impossible. OO design patterns make abstracting off APIs trivial.

The most simple and most useful is dependency injection. Note I am not talking about dependency injection frameworks with come with their own host of complexity and problems, but simply using the abstract factory pattern to wall off the external API and its structures from your business tier. 

This wall has many advantages: