Subscribe via e-mail: Coincidentally, shortly after I wrote the article for the GUI vs. CLI poll I came across a related topic. PowerShell did not only make the renaissance of the command line possible, the marketing buzz around it also tempts Windows administrators who never wrote a line of code before to program scripts to “automate” administration tasks. I would like to cite a paragraph from Robert B. Laughlin’s (winner of the Nobel Prize in Physics) book “A different Universe” (p. 68) that I am currently reading. (I highly recommend this book to everyone who is interested in Physics and the Philosophy of Physics).
One of the more interesting trends of the computer age is that physical science students are increasingly unwilling or unable to write computer code. I was very upset when I first observed this and took stern measures in my department to counteract it, much to the students’ chagrin, for I myself am very good at coding and consider it something any self-respecting technologist should know how to do. Eventually, however, I realized that the students were right and I was wrong, and stopped the crusade. Computer programming is one of those things in life, like fixing one’s own car, that is fascinating, fun, useful–and unacceptably time-consuming. The truth is that it is no longer cost-effective for most well-educated people to program their own computers, or even to learn how to do so. The wise use of a time is to spend a few bucks to buy a program that does what one wants, or in extreme cases, search the internet for free software.
If you replace “physical science students” with “system administrators” you have more or less the same situation in today’s IT departments. Only most recently some administrators seem to be enticed by the powers of PowerShell to write their own code again.
I’ve often seen IT pros making the same mistake that Laughlin made at first. They believe that “any self-respecting IT pro should know how to code” and programming certainly also is “fascinating, fun, and useful”.
But as Laughlin correctly acknowledges, it is also “unacceptably time-consuming” and therefore, as far as IT departments are concerned, unacceptably expensive. The point here is that professional developers can do the job for a much lower price, especially if the program is not only used in one IT department , but in hundreds or thousands around the globe.
In the early days of networking, you simply had no other choice than to write your own scripts to get the job done. But those times are over. Rest assured that almost every “automation problem” you face has been already encountered by other admins somewhere else. And then, it is most likely that someone wrote a program to solve the problem which you can buy or perhaps even get for free on the web.
Thus, don’t make the mistake just because “PowerShell rocks” of wasting your time with coding if you could as well solve the problem in minutes with a downloadable tool. We live in a more and more specialized world. Programming and system administration were once just one discipline. But both fields have developed and are now highly complex; they are now two very distinct disciplines. To be successful you have no other choice than to focus on just one of them. Of course, if you are a developer working in an IT department, then PowerShell is now the first choice when it comes to programming Windows scripts.
So far off course that I can’t even figure out where it came from.
I’ve been a systems administrator for 20 years on too many platforms to keep track of, and on each platform I honed my scripting skills to the point that I could build a safe and robust script to accomplish the specified task without excessive time being required.
When you talk about downloading a tool being more cost effective than scripting, you must be talking about very small environments. For example, my time costs the company about $75/hr. If I take a couple of hours to script a tool, that’s $150. If I can buy a tool for $50 that does the same thing but has to be licensed on 650 systems, that sets the company back $32,500. Which do you think would be an easier sell?
Yes, there are times with a comprehensive tool can be downloaded, but to make a generic statement that it’s not efficient for system admins to code or script (there is a difference), is not accurate. Even if you can download a free tool that seems like it does what you are looking for, there are invariably tweaks that have to be done to fit your environment so you still have to have the skills to modify the tool somehow.
You have some good points. However, I think that you misunderstood the core of the argument which is probably due the fact that I didn’t explain it well. It is not that I recommend that every time you have to solve an “automation problem” you should fire up your browser to find an appropriate tool.
My point rather is that there are very sophisticated management suites that solve all kinds of automation problems. That is, once you filled your toolbox with the GUI tools that fit to your environment, there will be no additional tweaking or learning. However, if you have to write a new script every time you come across an automation problem, it will cost your company more than just the $150 because it will sum up over time. I think we agree that a script that you hacked together in two hours only solves a very specific problem. But a $30.000 management suite can do little more than your tiny script. And don’t say that your company only paid once for the script but you can use it forever. You have to adapt the script every time your environment changes which costs additional money. You also forgot to mention that it costs you a considerable amount of time to keep yourself up-to-date with the latest scripting technology which probably is the biggest cost factor for your company.
Only since I started blogging I realized how many great admin tools are out there, some are free and some cost money. I found that most of them are worth their money. Otherwise these companies wouldn’t survive. Do-it-yourself is fun – yes – but only in rare cases cost-effective. Another word for this development is “industrialization”. It appears that IT management is now mature enough to become industrialized. However, I agree that there are still many networks in the wild that are not standardized enough to be ready for this step. Thus for many admins scripting is still a part of their daily work.
Scripting skills are popular and pretty much a requirement in the *nix world often because it is the only option. A valid argument is that most Windows automation can be accomplished using free software tool available on the web. However I would like to point out that many of these tools are not very well supported – if at all, and are often designed to do much more than the single task you are trying to accomplish. When you consider the sum of such tools introduced into a large environment, the complexity and redundancy of purpose they introduce would eventually become overwhelming, whereas single-task scripts using a preset standard would make supporting the environment much more cost effective.
I think the fact that most Windows management tools are designed to do more than a single task is one of their biggest advantages because this keeps the number of tools you need down. In large environments you usually have sophisticated systems management solutions that allow your to configure every bit on all your machines without writing a single line of code. I remember quite well that at my last employer we had quite a few scripts which have been written by different people over the years. Some of them left the organizations and nobody really knew how those scripts work. Modifying a script that has been written by someone else is usually a time consuming task. The real costs of a script often only become apparent years after it has been written. I hope they never run into problems with one of my scripts because I am sure it is mostly spaghetti code since I am not a professional developer. Thus I think the support problem you mentioned applies mostly to do-it-yourself automation tools and not to professional management solutions.
I think being a sysadmin who can code when I absolutely must, but of unfamiliarity such that it makes a simple script a drawn out excercise in Oreilly book digging, my lack of Powershell ability is a hinderance to me. I’m working to fix that.
Case in point… I have a big series of log files that no off-the-shelf tool is going to parse for me. All I want to do is extract IP addresses and timestamps and export those into a .csv that I can then play with in Excel to spot trends. If I were half as familiar with Powershell as I was once with Basica.exe and Turbo Pascal, it would be a done deal in 5 minutes. As it is, I go without that info.
There are certainly cases when a problem has to be solved with a script. The question is if isn’t cheaper if your company hires a professional programmer to write the program. You might also consider to change the application that produces non-standard log files that can’t be parsed with standard log file analyzers.
How on earth do you equate the computer skills of System Administrators with those of Physicists and Chemists?
Don’t you think that argument is a bit like saying that a long haul trucker shouldn’t bother learning to change a tire or check his oil because physical science students don’t need to.
Just because there’s a GUI tool to do something doesn’t mean that doing it by hand in a GUI tool every time is a better idea than writing a script you can reuse each time. Next you’ll be telling us that we shouldn’t do unattended software installs because filling out an answers file requires special skills that are a “waste of time” to learn.
Joel, you know me already well. Filling out answer files was yesterday. There are great GUI tools that allow you to create answer files. And who told you that you can’t reuse a GUI tool? I’ve never heard of one-way GUI tools.
I’d say a GUI tool that doesn’t allow to save and load settings is just a bad GUI tool.
I’ve studied physics and so I know that the situation is comparable. Those guys had to code a lot in former times but now it is not necessary anymore because most of the programs they need are already available. Re-inventing the wheel is never cost-effective. It is just a waste of time. This applies to all disciplines.
Why the fixation on the interface? If a GUI or CLI tool meets the need what is the difference? Use the best available tool for the task at hand.
I think I know for what you voted.
The main point is that in most cases you save time if your work with GUI tools. Especially if you use a tool only every now and then, it simply costs too much time to check the manual again for the correct syntax. I discussed other disadvantages of the CLI in this article.
Being a scripter myself, I don’t agree with one single word of what you say here. But that’s life… you can’t agree with anyone, I suppose
It is probably that I like scripting and CLI’s so much.
And I am so happy that Powershell has been closing the gaps between those “ITPro” and “Dev” guys that always liked to stay apart from each other, rather than trying to understand what the other was actually doing and try to see the world from the other’s perspective. In the Unix world there is no such a difference: sysadmins are programmers, and programmers are sysadmins too.
I don’t agree that they have to be two disciplines. Staying apart from each other is what causes finger-pointing. It would be better to try to think out of the box and try to see the world in the other guy’s shoes too.
Also, I am not saying that you must or should use the CLI everytime; IF there is a tool that does the job and can be leveraged, well – that’s fine for me of course! But sometimes there is no such a tool, or often it is too big, or too expensive… or it is not exactly what you need… or maybe, as Jim says in one of the comments, maybe you also need to learn and customize the tool…
In a number of cases, being able to “roll your own” is invaluable, IMHO.
Answer to Aszurom: have you tried LOGPARSER?
I don’t think the car analogy works. If I lifted my car’s hood I wouldn’t have any idea what I was looking at, I always take it to the shop. Then again, and here’s the key thing, when I take it to the shop the mechanic doesn’t need to ask me what I want the car to do, the outcome can be safely assumed. In fact no communication is needed except the price and how would I like to pay.
The situation in IT is very different. As someone who has been both developer and product manager, I know how difficult and time consuming it is to have one person to solve a problem that another person is facing. Not to mention the high failure rate. The reason is the difficulty of one person (the admin) giving another person (the developer) just enough information and expertise to solve the problem in the right way.
Admins encounter a lot of small problems, and when they do there is likely no off-the-shelf software to help, and handing the problem to internal development, or outsourcing it is expensive for the reasons noted above. We’ve found with our PowerShell offering particularly that admins find huge value in the fact that they can be more self-sufficient. The interface is easy and powerful enough that they can solve the problem themselves rather than going through these challenges.
You raise a deeper question of whether this is a “good thing”. I view programming as a form of communication, it’s communication between man and machine. It takes many years for people to learn to communicate with each other, but if you don’t do it you end up functionally illiterate and basically useless to society. As computers continue to dominate more of our lives I feel that those who cannot “communicate” with computers are trending more and more toward functionally illiterate. So until computers can communicate with us in our natural languages, learning to “communicate” in some sort of machine language is time well spent.
And how about the time you spend to master those mighty Admin suites? Is that not expensive?
And even when you do, there always are situations so specific that only an “infinitely” flexible tool (like scripting/programming) can handle. But then, scripting as I use it is only intended for that kind of situations.
I wouldn’t hire an Windows Admin who doesn’t talk DOS and VBS at least, but I certainly don’t expect him to do his job using 1000+ spaghetti scripts. By all means, use a clean comprehensive point&click solution for the main task, but don’t tell me you’re limited by it when a script can solve specific problems it can’t.