Kathy Sierra has another great article up, wondering whether better tools make us dumber (e.g., does the use of calculators mean we don’t need to learn math). The article brought to mind a lot of the fear I see among sysadmins when I discuss tools like Puppet. Sysadmins aren’t so much concerned that better tools will make them dumber but rather that better tools will allow dumber people to replace them.
Kathy’s conclusion is that you still have to understand what you’re doing, but I think she missed the opportunity to talk about why we use better tools.
Better tools have a long history of making people’s lives easier, whether it’s allowing an expert to spend less time on the tedious bits (e.g., AutoDesk and architects) or allowing laymen to edge into the area of experts (e.g., Photoshop and graphic design). If your job currently consists of all of the tedious bits, such that everything you’re an expert in can be pretty easily replaced with a tool, then you’re always at risk of becoming obsolete, but if your value-add is the understanding behind the tools and the tedium just makes you less efficient, then you should love these better tools.
Unfortunately, I’ve seen too many sysadmins fall in love with the tedium of knowing all the little bits of all the systems they manage and not worry so much about understanding the higher-level nature of their jobs. I think this is part of why there are so few good, new tools being developed in this space, why sysadmins generally provide such poor service to their employers (e.g., slow deployments, lack of metrics, lack of transparency), and why they’re so afraid of using better tools.
To those sysadmins who are afraid of automating themselves out of a job, you should ask yourself where your value is: Is it the tedious parts, or is it the understanding behind the job?
Tool Power and Transparency
In terms of what the tool provides, Kathy makes the point that you can only effectively use higher-power tools if you understand the system behind the tool. I would further make the point that the best way to make more powerful tools is to make sure they have a clear model that extends from the user interface through to the tedious bits. This allows those who really understand the system to clearly differentiate themselves from those who just know the tool, because their understanding immediately makes them more effective with the better tools.
One of the big reasons I decided to start my own project rather than trying to work with another tool is that the vast majority of config-mgmt tools out there are opaque at the edges, meaning that no matter how much of an expert you are, you can’t immediately turn your understanding into effectiveness with them.
For instance, both LCFG and SmartFrog have modules that cover large and essentially random chunks of functionality. LCFG has a large sendmail module used for, of course, managing sendmail. This module, like all other LCFG modules, has many parameters that can be set on it to configure clients. The problem is that no matter how much of an expert I am on Sendmail, I can’t apply that expertise to LCFG without first studying the Sendmail module to figure out how it maps the parameters to the bits on disk. If the module instead exposed the mental model behind managing Sendmail, and I could just apply that model using this more powerful tool, then if I already had a good mental model I would be far ahead of those who were just looking to avoid understanding.
I think these opaque edges are fundamentally flawed, because they don’t allow the real experts, those who really understand the resource being managed but are tired of writing cf files, to differentiate themselves from those who don’t know much about it and like the module because they don’t need to learn as much. Thus, Puppet’s resource abstraction layer really is fundamental to what makes it a powerful tool, and as I create higher layers in my tool stack, I can promise you’ll always have clean models that translate transparently from one layer to the next, and I’ll never ship an opaque layer that makes existing understanding useless. In fact, if anything, my goal is to create layers that model existing understanding, so you can immediately apply that understanding you have but skip all the tedious bits you hate.
Of course, Sendmail isn’t the best example, because not many people really need much understanding there these days, but the same is true for things like volume management or package installation. People of any skill level will be able to get more done with better tools, but tools that allow experts to apply their existing understanding with less tedium and more power are far superior.
