An important DevOps word: toolmakers
The word "toolmaker" has great explanatory power to help IT people understand how their world is changing. Those who come from the Run domain of IT (as compared to Build) are becoming toolsmiths.
A word I don't hear much if at all in DevOps conversations is "toolmakers". [Update: that's because they usually say "toolsmith". (Thanks Damon Edwards.) But it seems to be used as a job description more than an explanatory concept for how Ops is changing]
I think this is a really important concept and the word is a powerful one for communicating it. When I hear explanations of DevOps, especially of what it means to non-developers, I find myself waiting to hear talk of tool makers. And I seldom do.
I'm not talking about the software vendors here, which is the most common way the word "toolmakers" is used around DevOps ("tool makers like Atlassian, Chef, CloudBees, ..."). I'm talking in the old-fashioned sense of people within the factory who make the tools that the production line uses. Now that manufacturing has moved off-shore, I guess many readers have never seen a guy machining a die to go in a press to stamp out a mysteriously shaped widget that ends up deep in a washing machine , as I did four decades ago.
As I heard on a podcast: "Operations are moving from being the people who do the thing to being the people who build the thing that does the thing".
Or on Twitter:
"The SysAdmin is an anachronism. It's all software now, so they are now software developers, not infrastructure babysitters." https://twitter.com/glennodonnell/status/734876833997590528
More precisely, a number of roles in IT are moving from being the person who does the thing to creating the mechanism so that others may do that thing. In other words we move from being functional people to being tool makers in the IT factory.
So for example, the professional test team go from mindlessly walking through test scripts to being the makers and custodians of the testing automation framework. These testers will then insert tests in that framework for generic and standard tests, but they will also allow the developers to create and insert their own tests into the testing framework for their own code. This plays into Test Driven Development (TDD), a very cool concept: if your tests are written in a sufficiently high level syntax, they become a sufficient definition of your design requirements. Put another way, if your requirements are defined in the right way, they become the tests you test your code against, and once it passes the tests then by definition it meets requirements. if the code fails, change the tests then code to the new tests. (Corollary implication: automated testing means test early, comprehensively, and often).
There's another example of course: the sysadms go from mindlessly building server instances from developers' manual instructions, to creating the automation to allow the developers to create their own virtual server instances using infrastructure as code (another massive concept changing the way we do IT). The Operations people become the custodians of the operational environment, in which they monitor the quantity and quality of the servers being created by the development people, and they adjust and enhance the automation engine to control what the developers do, in order to enforce policies, manage risk, control costs, and maintain quality. (Corollary implications: production-like environemnts on laptops; containerisation; immutable servers slaughtered at will; use of public server clouds...).
THIS IS HUGE. If you work in Operations (as a sysadm, DBA, tester, network engineer...) you owe it to your career to either
- get a job with the Cloud providers who still build actual infrastructure, or
- start developing your scripting skills to be either
- a toolmaker or
- an infrastructure-code-developer on a Build team
Because as DevOps gives the tools to the Build people to create their own infrastructure, our roles are changing, (as I wrote about recently).
Maybe the word "toolmakers" doesn't bring the right concept to mind for the youngsters, and it will get confused with the software vendors providing the tools to make the tools. If so, what's a better word?