Law of the Instrument
Hey!
Welcome back to another week of musings.
With spring in full bloom these past weeks, the weather here in the Bay has been great. We had some random rain on Saturday but enjoyed Sunday under the sun.
Was this forwarded to you? You can subscribe here!
While on Twitter (X?) I came across this tweet by someone asking why SQLite compiled SQL statements into bytecode to execute them.
The author of SQLite mentioned that during inception, he didn't know much about database engines; instead, he knew a lot more about compilers, so it was natural (for him) to treat the problem as a compiler problem.
We all start by reaching for the solutions at hand when faced with a problem. https://t.co/KfvgZqYqRD
— @norootcause@hachyderm.io on mastodon (@norootcause) April 29, 2024
That made me think about the Law of the Instrument, a common law mentioned in software engineering.
"If the only tool you have is a hammer, it is tempting to treat everything as if it were a nail."
Familiar Tools
Often, we all fall into this bias and sometimes might be able to notice it.
I've come repeatedly when reviewing past projects or even when corrective actions arise after incidents. It is often faster to solve with a familiar tool that breaks the resistance to thinking about the "right" or better long-term solution. I often see this with logs; people tend to rely on adding more and more fields to the log and then having a tool parse and count the data points or graph it out, etc. As opposed to leveraging dedicated metrics. Why are we having that issue in the first place?
Learning to avoid
As usual, with anything in software, it depends. We should always look for the best choice, which means looking beyond available tools.
It depends because time is also a constraint in our projects, and we have to balance an exhaustive search with getting things done. On the other hand, looking for tools outside our current knowledge is important, and sometimes raising your hand and saying, "We need to pursue this option," even if it will take a bit longer, makes sense.
Not everything is software
I recently realized that sometimes we rely too much on building or buying more software to solve problems when it might be more about changing the process.
We often jump straight to "build vs. buy," but what if we didn't do either and changed how we do things? Would we need even more software to maintain or buy?
Your turn!
Have you ever thought about problems that were solved with prior tools as opposed to researching more? Or maybe you thought there was another option but chose a familiar solution?
Let me know by replying to this email!
Happy coding!
Things I discovered in the past week
- SREcon24 Americas - What Is Incident Severity, but a Lie Agreed Upon? SRECon24 Americas' videos are available now on YouTube. I've been watching a few, and this one catched my attention.
- The Anomalies of Disruption from MIT Sloan, a look at the "anomalies" that didn't fit the original Innovator's Dilemma, as described by Clayton Christensen, but ended up working as one.
website | twitter | github | linkedin | mastodon | among others