Hammers and Screwdrivers
There's an old adage that says, "If the only tool you have is a hammer, every problem begins to look like a nail." In IT this often translates to a rule that we should never select the tool first. Rather, define our problem and only then, choose the tool. This is generally sound advice.
There are, of course, caveats.?
We are all familiar with feature creep. This is the inexorable tendency for requirement documents – especially those emerging from committee – to get bigger, more comprehensive, more Swiss-Army-Knife in every conceivable way. Imagine being on a committee and being tasked with selecting a product from many. The larger that committee, the greater the tendency for even niche nice-to-haves to become a must-have. When that requirements document is finally circulated it includes everything from pounding nails to embroidering exquisite lace doilies.?
From the product vendor side it then makes sense to include these niche features into their product. When the inevitable comparison matrix is populated, their product will then check off all the boxes. Their product wins. Of course this is not necessarily always bad. Microsoft Word famously rose to market-leading status because of this approach and one could argue that this also benefited the consumer.
Alas, IT tools are rarely as simple as a hammer or a word processor. Our utilities, our IDEs, our platforms are necessarily complex to serve the requirements of our complex environments. Even in Unix/Linux land, where the mantra "Do one thing well" is oft repeated, we have editors that can play MP3s and file managers that can browse the web.?
Once a tool is selected, rather than adjusting workflows to align with the tool, many instead attempt to deform the tool to make it work as the workflow dictates. In essence this is not pounding the screw with a hammer but rather welding a screwdriver onto the hammer. Neither the hammer nor the screw benefits from this approach.
领英推荐
So we "tool-hop." The given tool doesn't pound nails and embroider doilies?? Let's find another tool.?
As IT professionals, we are compensated for our ability to integrate complex tools into our workflows. This does not absolve vendors from providing products that simplify these workflows, but we need to disabuse ourselves of the expectation that complex toolsets will auto-magically integrate into our environments. There is a ramp-up involved, sometimes involving hours of reading, testing and smashed fingers. Only through this learning process can we overcome the paralysis that often occurs when dealing with the complex.
To this end I have adopted an approaching to dealing with complex technology. Whether it's Kubernetes or Ansible or CUDA programming or whatever tool needs to be understood, I choose a moderately complex task that I believe can be completed in a weekend. With luck I can complete the task within a weekend or too. If I'm luckier it takes far longer and I gain a lot more knowledge that I had anticipated. Yes, it can be frustrating but the journey is worth it.
On a side note, the manual page for the ubiquitous Linux/Unix command ls is itself several pages long. It wasn't always this way. At one point, sorting output by name or date required the use of other utilities such as awk or sed. Now it's just a flag. I still regularly see code that foregoes the built-in sorting in favor of additional scripting. My advice: Learn the tool.
Reading List
Enterprise Account Manager @ Orca Security
2 年Well said Kwan!