While working with a customer recently, I heard this sentence: a tool is better than a script. The reference was that this customer preferred a known, tested, approved tool for most of their staff rather than a script built, lightly tested, and perhaps changeable by anyone in their organization.
I was surprised, because in many ways, I’ve depended way more on scripts, more often, than “tools” in my career. Often I struggled to find tools that actually worked in the way I wanted them to and built them myself with Unix shell utilities, VB Script, PowerShell, or some combination of those or other technologies.
I asked them if they wouldn’t prefer to customize things and let one of their senior people write their tools. They said that it wasn’t necessarily a problem for a few people, but too many people might edit and change the script, even the senior people, and then others couldn’t depend on them. They weren’t sure if they were reliable if a known script wasn’t being run. Even among their senior people, someone would edit a script then they thought something wasn’t quite right, or there was a new requirement and then the script would return unpredictable results.
I felt they didn’t completely trust their staff, but I also understand. I’ve changed my own “tools” and broken them or gotten back incorrect results. Depending on what the script did, and how busy I was, I might not even notice the problems. That might cause me problems if I expect data or actions to occur one way and they work differently.
Scripts can be changed by anyone. The results might not be what’s expected on a team. I get that. At some point in my career, I put all our DBA “scripts” or “tools” into a version control system and we had a path to the trunk (main) branch of them that was read-only, so that we knew what was being executed. If we wanted to change the script, we had to open an branch in the repo, make our edits, and then have another DBA approve the change before it would be merged into the main, and subsequently pulled into the folder in our path. This didn’t prevent changes, but it did give us some versions and history of changes.
There’s a balance between flexibility and customization that is challenging to tread amongst team members. Sometimes a known, reliable execution is better than one that changes too quickly. We’ve been asked at Redgate Software to ensure people using Redgate Monitor can audit what actions are taken in the tool. Sometimes a team member changes a setting, such as an alert threshold, and other team members aren’t aware. That can impact their ability to diagnose problems when they assume the tool works one way, but it’s actually working another way.
Tools we decide to use, whether purchased or OSS, won’t always do what we need. There is a requirement to build our own, but we also need some expectation and assumption of how they work. Especially in a team. I don’t want to have to re-read the code every time I run a tool; I should know how it works.
At the same time, I can’t have every tool change each time someone wants something new. I love sp_whoisactive, but I depend on it working a certain way and wouldn’t want Grant to change how it reports data unless I know about the change.
Working in a team requires teamwork, which means that whatever type of tools we buy/download/build, we need to ensure we all are aware of how they work.
Steve Jones
Listen to the podcast at Libsyn, Spotify, or iTunes.
Note, podcasts are only available for a limited time online.
