Every Tool You Use Is a Liability

Many years ago, as a young software apprentice trying to follow all kinds of code put forth by the gods of computing I was enamoured with unix culture, its focus on simplicity in particular.

Down that path, my interests led me towards becoming an employed operations guy and with that eventually to learn a language aptly described as the “Swiss Army Chainsaw” of systems administration. Perl at the time seemed like the perfect fit to glue all of those focused unix tools together in a very pragmatic way!

I still remember vividly, first reading this infinitely promising sentence from the Llama bible:

 

“Easy things should be easy, and hard things should be possible.”

– Larry Wall

 

Though ever since, I’ve seemingly misunderstood the meaning of this quote, perpetually recalling it through the lens of my own optimism-bias… I too would embark the OSS Unix, joining the CPAN crew on its continuing mission to explore strange new worlds and to go where no sane engineer had gone before!

Well, in reality I still haven’t found the promised land and I secretly have known why for a long time: The black box is a lie.

In software leaky abstractions are everywhere, by repeating stories omitting this fact or telling otherwise we not only harm ourselves but most importantly those trusting and relying on us.

If we truly want to reap the benefits of our internet-enabled collaborative efforts we all need to level-up, meaning we have to understand our tools top-to-bottom and bottom-to-top.

Of course, that is even less realistic than naïvely applying conclusions of the “Hard things should be possible? CHALLENGE ACCEPTED.” variety on far too many occasions.

The solution is the old, battle-proven unix adage of less is more.

 

“A change in perspective is worth 80 IQ points.”

– Alan Kay

 

Let’s define what should be considered “tools” for the human animal “professionally” working with computers, the pinnacle of all its tools yet created:

• Programming languages
• Libraries
• Frameworks
• Build tools
• Development environments
• Production environments
• etc…

A specific and current example of my own would be getting to grips with using VMware Fusion with Vagrant. There is so much that can go wrong with complicated development environments, especially if you want to replicate a micro-service architecture locally…fighting with packer, tuning VMware vmx configurations, etc.

Better to go with a more popular, hence well-tested Virtualbox based setup or maybe no setup at all?

How about “outsourcing” your development environment to a “real” server with identical configuration down to the very operating system image so you only have to wrestle with setting up the thing which needs to be bullet-proof anyway? If you are already coding with vim or emacs, why not?

Though, if your host location is too many hops away you could run into latency issues introducing lag to your development feedback-loop and therefore seriously hamper your own productivity..

So, the pragmatic solution for backend-development would probably be something like a single Linux VM (with VMware \o/) and Docker, skipping on Vagrant completely…

 

“Every tool you use is a liability, pick your abstractions well and as few as possible.”

– Every scarred software engineer

 

I’m still largely undecided on how to finally resolve this particular problem but at least I know that the best kind of tool is no tool at all.

---

Update: I finally found a satisfying solution for my example problem.