IT Decision Maker

Blog archive

Is Your Team Wasting Time with Scripting?

I'm an MVP Award recipient from Microsoft, primarily for my work with its PowerShell technology, and you don't often see me use the words "wasting time" and "scripting" in the same sentence. But now it's out there: I truly believe that a lot of IT teams -- if not most -- are wasting time messing around with the scripts.

Let me be clear and state that this is not a blanket condemnation of scripting or of PowerShell. Quite the contrary, in fact. I believe in the right tool for the right job. Scripting is the right tool when the job is one of two things: First, whenever you have to automate some business process that is unique to your organization, and which cannot be efficiently accomplished in any other way. Second, whenever you need to automate some process that is rarely performed. In that instance, you're not really automating something that's truly repetitive; you may be automating it because it's done so infrequently that nobody accurately remembers how to do it. Either scenario points directly to scripting.

So what doesn't point to scripting? The automation of tasks -- particularly complex ones -- that are common across our industry, and which could be better and often less expensively accomplished by a third-party tool

Some elaboration is in probably in order. First, you have to understand that I do not expect Microsoft to provide tools to accomplish every little task that every organization in the world might want to perform with the company's products. Microsoft's job, in my view, is to provide a baseline set of tools and a solid underlying platform, and to do so in a way that enables third parties (whether your team or ISVs) to build additional domain-specific tools on top of what Microsoft provides. If your organization, for example, frequently needs to scan through file and folder ACLs to see who has permission to what, then I don't necessarily expect Microsoft to put a tool for that in the box. It just isn't a universally needed task (although I admit that this particular example is becoming pretty widespread), and even amongst the organizations that do need to perform this task there's a lot of variation in how they need the results presented.

So, third-party tools are, and should be, a way of life. When should you not build them yourself, and instead go to a third-party ISV for them? When those tasks are a critical, almost daily part of your business. Let's switch examples for a moment and consider the need to collect Active Directory auditing events into a single, consolidated, searchable log. You could certainly write scripts to do that, and I have a number of consulting clients who've done just that. They're limited to the information in the event log, of course, and that information isn't always the most human-readable. Most of the examples I've seen required an administrator to spend about a week building, and then perhaps 10 hours a month maintaining and tweaking. So in the first year, that's about $7,000 in man-hours. Folks usually spend a lot more time consuming that data -- the two customers I've worked with who took the time to quantify that work spent an average of 40 man-hours per month sorting, filtering, searching and presenting data from those raw event logs. They spent another 20 hours per month doing what I call "dealing with" the data -- for example, translating event IDs into a meaningful message, looking up SIDs and GUIDs, and so forth. All work made necessary by the low-level nature of the data in the logs. They assigned a value of about $30,000 per year to that effort. Round number, $37,000 per year total.

That's a lot of money. These same organizations steadfastly refused to bring in a third-party change auditing solution for close to seven years, meaning they spent about $260,000 in man-hours. One of them is still doing so. The other got sick and tired of the additional hidden costs of scripting -- like when its Script Guru left the company, and someone else had to spend three weeks coming up to speed on the scripts ($5,000 more to the bill). That company runs a 6,000-user Active Directory domain, and their third-party auditing solution cost them $108,000 in the first year and about $20,000 in annual maintenance fees thereafter. Five-year cost: $188,000. It's in the first year now, and its time commit on those same tasks is nearly zero because it selected a tool that provides exactly what it needs, more or less automatically. Even reports are produced and mailed out automatically.

That's just one example, and the point isn't so much that one company's specific numbers as it is the general theme: Scripting isn't free. It requires man-hours, even just to maintain, and comes with a big risk that your "Script Guru" will leave you in a lurch at some point. You can mitigate that by educating more of your troops in scripting, of course, but do so strategically. Focus on the tasks that don't need to be run often (making script maintenance less expensive), or focus on tasks for which an affordable tool simply isn't available. The argument, "Well, if they weren't writing scripts, we wouldn't need those people" doesn't hold water -- there's always work for an admin. Let them be admins, not software developers. Look closely and you may find that tools to automate daily, mission-critical tasks are less expensive in the long run, provide better functionality than you could script yourself and do a better job of meeting all of your organization's business goals.

I'm not saying don't script. I'm saying script when it makes sense. Be a strategic decision maker.

Posted by Don Jones on 04/25/2011 at 1:14 PM

comments powered by Disqus

Reader Comments:

Fri, May 13, 2011 Amused

I'm looking forward to coming back to this article in the next few days to see just how many people who can't script jump on here barking about how we don't need scripting. LOL!

Tue, May 10, 2011

Did you check the no. 1 Automation tool called Automation Anywhere using which you can autoamte any process without having to learn scripting or programming.

Wed, Apr 27, 2011 Dan Iowa

While I can see that point of view, I have yet to see "too much scripting". Instead I see these used as excuses for not doing scripting. "I am an Admin not a developer." or "I install things I don't do code." I agree that it is often cheaper to purchase a product than to write scripts to do something, but sometimes it can take days or weeks just to get approval for the purchase of a product to do something that be scripted in a day. Oddly enough, my example was going to be auditing active directory logs. Took about 16 hours to build the initial solution, and logparser still handles the reporting just fine. I can't fathom what one would do for 10 hours a month to "maintain" the code. (It just runs.) Truth be told we are looking to replace it with a purchased tool that has more features, but in the meantime we are getting a minimal job done with scripting while we have been talking about buying a tool since before I wrote the scripts.

Tue, Apr 26, 2011 Jeffrey Snover

Great article. Once again Don, you are the voice of reason and thoughtfulness in all things IT. The PowerShell team is dedicated to the success of IT Pros and NOT dedicated to getting everyone to write PowerShell for everything. We think PowerShell is a necessary tool for lots of scenarios but often people are better off with products, their existing VBScripts or just doing something by hand. As you say, the key thing is to be thoughtful about it. You missed MY personal favorite example of where people are wasting time scripting. That is when there is a community solution (script) for their problem. The PowerShell community is amazing and generous. There are lots of scripts out there and people's first reaction should be to see what the community has to offer before they go script their own solution. Often you'll find exactly what you need or something close that you can modify and share back with the community. Enjoy! Jeffrey Snover [MSFT] Distinguished Engineer

Mon, Apr 25, 2011

This is so true. Almost everything I need to can be done with an existing free tool, which sometimes IS a raw script, but one which was written by someone else. That is not to say that sometimes you really do need your own scripting skills. Another thing is that I often can just use batch files as my scripting method. If it works well, what different does it make if it's an old technology?

Mon, Apr 25, 2011

Thank you. I have been ranting about this for years. More powerful scripting engines seem to mean more attempts at home grown solutions to complex problems. This leaves the company open to unexpected and potentially serious problems.

Scripting should usually be kept to basic admin issues where a quick extraction of information or quick adjustments of a configuration is necessary.

Building facy solutions is fun and useful as a learning tool. It is a waste of time as most users are not trained in Windows internals or in ‘Systems’ technology and so may write much more code than is required. Leave the Windows programming to trained programmers.

Add Your Comment Now:

Your Name:(optional)
Your Email:(optional)
Your Location:(optional)
Please type the letters/numbers you see above

Redmond Tech Watch

Sign up for our newsletter.

I agree to this site's Privacy Policy.