Results of the PowerShell poll and about the automation myth

• Author
• Recent Posts

Michael Pietroforte

Michael Pietroforte is the founder and editor in chief of 4sysops. He has more than 35 years of experience in IT management and system administration.

Latest posts by Michael Pietroforte (see all)

• Poll: How reliable are ChatGPT and Bing Chat? - Tue, May 23 2023
• Pip install Boto3 - Thu, Mar 24 2022
• Install Boto3 (AWS SDK for Python) in Visual Studio Code (VS Code) on Windows - Wed, Feb 23 2022

In our poll, I asked if you prefer to be an admin or a devop (a hybrid of an admin and a developer). Of the 438 admins who took part in that poll, 56% prefer to stay an admin and 44% want to be a devop.

I think that is a good result for PowerShell. When I asked a few years ago if the command line or a GUI is preferred for system administration, 64% preferred GUIs. However, I must admit I am unsure if the poll here is representative of all Windows admins. Since the term “PowerShell” appears in the title, readers of the article probably consisted mostly of admins who are interested in PowerShell; those admins are more likely to have experience with PowerShell and are more likely to vote pro PowerShell.

But I think it is also obvious that a fundamental shift is taking place in the attitude of Windows admins. Microsoft’s constant push of PowerShell is beginning to take effect. The more admins exist who learned PowerShell, the more likely it is that they want to make use of their skills. You want to know what I prefer?

I definitely would love to be a devop. Coding is fun. It is perhaps the most rewarding work in IT. Like most “IT veterans,” I started scripting with UNIX scripts, MS DOS batch scripts, and scripting languages of a few other operating systems that are long forgotten. I must admit that I never liked Microsoft’s scripting languages. In the Windows world, I first preferred to “script” with Visual Basic and, when .NET was introduced, I moved straight to C#.

I mention this because I want to stress that I have no fear of contact with scripting or a CLI. However, I believe that these changes we now see in the Windows world are going in the wrong direction. It is one thing if you enjoy doing something and another if it is efficient.

The PowerShell automation myth

This brings me to the second topic I mentioned in the title of this post. It might be a bit off topic, but I want to use this opportunity to address something that has been on my mind for quite some time. It is this new mantra that we need PowerShell to automate IT tasks.

The story usually goes like this: There is this unfortunate Windows admin who has to perform a certain task on a few hundred or perhaps a few thousand objects (computers, users, etc.), and he sits there for hours or perhaps days clicking each object until his forefinger refuses to obey. And, the next morning, all starts over again. Click-click-click…

Yes, this poor fellow is a typical click-click GUI admin who just doesn’t know better. But now comes the great PowerShell geek who, with a few cmdlets and a few pipes, automates the tedious task within minutes, if not seconds. If only Sisyphus knew about PowerShell.

Please excuse my somewhat sarcastic introduction. I just couldn’t help myself. I don’t know the origin of this story, but my guess is that it comes from a developer, perhaps a former Linux admirer, who doesn’t have much experience in Windows administration. These days, you often hear this story from Microsoft officials, which explains why many Windows admins now take it for granted—and I believe without really thinking it through.

It seems so evident. PowerShell is about automation, and GUI tools stand for doing everything manually. I have been doing Windows administration for some time now, but I never observed the above myth in reality.

First of all, what does automation mean? Wikipedia says:

Automation is the use of machines, control systems and information technologies to optimize productivity in the production of goods and delivery of services.

Thus, whenever you use a computer program (and GUI tools are computer programs as such), you automate a certain task.

The history of the automation myth

Actually, it is safe to say that the main reason why Microsoft could take over corporate IT quasi overnight, in a market that was dominated by UNIX systems with their shell scripters, was the introduction of GUI tools that allowed admins to automate IT tasks without the need to script. This boosted the productivity in IT by magnitudes. And the main reason why Linux never endangered Microsoft’s desktop monopoly was that large parts of the Linux community insisted that GUI tools are something for wimps.

But then came a time when a few organizations, mostly in the public sector, were somewhat displeased by Microsoft’s licensing policy and decided to move to Linux anyway. This triggered the old Gates angst that you can’t compete with free, and so big companies in particular were asked what they found so appealing about Linux. “Better scripting capabilities” was probably first on the list, followed by a “smaller footprint of server systems because you can run Linux without GUI.” PowerShell and Server Core were Microsoft’s answers, albeit both found their way into the Windows world only after the Linux hype was already over.

PowerShell was a big success because it is indeed a great scripting language. This, in turn, resulted in some changes within Microsoft’s top management structure. Microsoft then began to exaggerate things, and the first releases of the automation mantra meme virus were implanted in the brains of admins. PowerShell became more and more dominant, and GUI administration suffered in the sense that, for first the time in the history of Windows, some important configuration tasks could only be done on the command prompt. This culminated in the public belittlement of GUI administrators as click-click admins by Microsoft officials.

The click-click admin

Now that we know where it all came from, we can try to understand what is wrong with the myth of the click-click Windows admin. Of course, there is no admin out there who clicks hundreds of objects to get a single task done. The truth is that the vast majority of automation tasks can be done with GUI tools, and most of them are from the Windows maker. Think of Group Policy, which allows you to configure thousands of computers with a few mouse clicks, or Configuration Manager, which deploys software to tens of thousands of computers if necessary.

Try automation in these magnitudes with PowerShell. Good luck! And if you really can, you definitely have the wrong job; you had better join the Configuration Manager team. As a matter of fact, GUI tools are often the far better choice when it comes to automation of system administration tasks!

Yeah, I already hear the automation geeks: “Thaaat is not what we mean by automation. We mean this kind of automation that cannot be done with GUI tools.” Now we are talking. What kind of automation tasks would that be? Automation tasks that can’t be done with the tools that Microsoft offers have always existed. Traditionally, you had two options in such a case. The first option is to look for a third-party tool that allows you to get the job done and, if none exists, write a script. The second option is nothing else than building your own system management tool whether it has a GUI or not. In most cases, the first option is the better choice.

The GUI automation ecosystem

One of the greatest achievements of Microsoft was to create a huge ecosystem of system administration tools. I only started to notice how big this ecosystem is after I began to write part time as a freelance journalist 16 years ago, and again about seven years ago when I started 4sysops. The ecosystem has been growing ever since at a remarkable pace.

Just look at the huge number of free admin tools we covered over the years. Trust me, this is only the tip of the iceberg. Even after doing system administration for three decades, I stumble upon new tools and software companies I have never heard of. And, as a blogger, it is my job to know about these things. I can only imagine that the average admin has no clue about the number of automation GUI tools out there.

However, the all-time greatest tool for system administrators helps you. This tool is called is Google. Nowadays, it is so easy to find the right tool for your automation task. Why reinvent the wheel when it has been done before?

You might argue that most of the tools are not free and you can script with PowerShell at no cost. Is that so? At no cost? I’m guessing that you don’t work for free, right? The time you spend for scripting could perhaps be used for something else. If not, your employer might consider reducing the number of admins in your organization.

My point is that a software company with skilled developers who do nothing other than code all day and produce automation tools, not just for one company but for many, can most likely create a more efficient, more reliable, and more secure automation tool, at lower costs, than can a devop with such limited coding experience that much more time is spent tinkering with getting the syntax right.

Yes, there are still some special environments where scripting is required. Traditionally, small and mid-sized companies hired contractors for this task, whereas large companies often have their own developer teams. For THEM, PowerShell is certainly a godsend.

Hybrids and specialists

However, I doubt that a hybrid of an admin and a developer makes any sense. Hybrids don’t have a good stand in evolution where specialization advances with time. (Nature seems to have a sense for this, as hybrids such as mules usually are not even able to have offspring.) Specialization increases efficiency and productivity. This was Microsoft’s achievement when sysops (as they were often called at these times) and developers became two distinct species.

Turning back the wheel of time would only make sense if something fundamentally changed in IT that justified this step. The only reason I can think of is that the variety of corporate IT has been growing faster than the Microsoft ecosystem, and the automation tool makers can no longer cope with the quickly growing complexity. We discussed this point in the new 4sysops forum, and I came to the conclusion that all recent changes, such as virtualization or cloud computing, only increased the standardization of IT and therefore decreased the need to script. In standardized environments, all automation tools have already been built by specialists, and hybrids are not needed. Scripting dominates in heterogeneous ecosystems. I don’t see this trend in IT.

Microsoft’s new user interface weakness

I believe that Microsoft will make a big strategic mistake if they continue pushing admins into a role where they waste time with mastering syntax instead of doing real IT management at a higher abstraction level.

As long as there is no competition for the Windows desktop in corporate IT, this won’t harm the ecosystem in a big way. However, we’ve seen that Microsoft’s wrong decisions about user interfaces have opened the doors for competitors in the consumer market. Everything else in IT moves toward easier and more intuitive-to-use interfaces. As computers become more and more powerful, they can adapt better and better to the human way of interaction.

The invention of GUIs and the mouse was one step in this direction, touchscreens the next. Old-fashioned command-line interfaces, where humans use machine-friendly languages to communicate with computers, are not the future. That’s for sure. As much as I love to code, there is one thing I like much more, and this is high tech. CLIs are low-tech instruments of the past. We don’t need the renaissance of anything in IT. What was once Microsoft’s strength—that is, to build intuitive user interfaces—has become a weakness.

What can you do?

So what can you do as an admin? Does it make sense to say nay to PowerShell? Of course not! First of all, you don’t really have a choice. You simply need PowerShell now for many administration tasks just because Microsoft doesn’t offer the corresponding GUI commands.

Second, there have always been some tasks where a little script can prove helpful because buying a tool would be overkill. Coding is fun and it broadens your horizon. With PowerShell, Microsoft offers for the first time a scripting language that is worth learning, and it is really not a big deal. Does this make you a devop? No! But scripting was always part of system administration, and it will stay that way until Ray Kurzweil succeeds at Google and builds a natural language interface (NLI).

Just don’t fall into the trap of the automation myth and start playing developer whenever you come across a task that needs more than three mouse clicks. A real geek has a good overview about the automation tools that have already been built by others. You can find many great GUI automation tools, as well as free PowerShell scripts that you can modify for your purpose, on the Internet. Automation does not mean to manually create a script with endless keyboard click-click-clicks; it just means that you let the computer do the work for you and in most cases with the software that has been built by others.

And the PowerShell CLI? If you are a good keyboard clicker, why not? Just don’t think that you will need fewer clicks than the mouse clicker next door. A picture is worth a thousand words, a single mouse click often stands for millions of keyboard clicks.

Click, click…