Scripts are an ancient and honorable part of IT. Since the beginning of time (or at least computer time), programmers have been writing scripts – in perl, bash, all sorts of languages and command-line tools – to do jobs such as tying applications together.
As a result, the older an IT organization is, the more scripts it is likely to have. And unlike applications, which have a hope of being updated or retired, scripts are seldom reviewed once they're put into production.
Scripts also tend to grow over time. Like fungus. A little tweak here, an added feature there, and that simple little script is morphed and mutated into something nearly unrecognizable, even by the person who wrote the original script.
All too often, the critical documentation for a script was never written down. It is in the head of the programmer. And when that programmer moves on, it can be anything from difficult to near-impossible for her successor, two or three generations removed, to figure out just what the script is doing.
Finally, scripts are almost always an inefficient way to do something. Even a compiled script is usually slower and uses more resources than a purpose-built application.
Of course, not everything in your script closet is ripe for rewriting or replacement. You undoubtedly have some scripts that are either irreplaceable or not worth the time and effort. The smart thing to do is leave those alone. You have enough to do replacing the ones that really need it.
“If It Ain't Broke, Don't Fix It”
“If it ain't broke don't fix it” is a powerful argument against messing with your scripts. However keep in mind that there are different values of “broke.” In a lot of cases, a script runs, but it runs slowly, consumes a lot of resources, is hard to maintain, or suffers from other problems.
Unfortunately the tendency in these cases is to leave the script alone, or just keep patching it. The result is a waste of time and resources that would be better applied to replacing the script entirely.
There are some scripts that programmers are afraid to mess with because they don't really understand them and they don't want the side effects. These are scripts that desperately need to be replaced, or at the very least, take the time to heavily document them inline. Save the next person who looks at this monstrosity from having to figure it out; after all, that person might be you, six months down the line.
Getting Rid Of Scripts
The first step in cleaning the script closet is to ask yourself: Is this script really necessary? In a surprising number of cases the answer is “no.” The script may have been used to perform an obsolete operation or to fix a flaw that no longer exists. Or the IT environment may have changed so much that the script is simply irrelevant.
Scripts related to storage are particularly prone to this phenomenon. As storage technologies have changed or equipment was updated, the scripts didn’t follow suit. As a result you have scripts that do things you no longer need done (managing obsolete tape drives, for example) or which can be done more easily in an application.
One way to get rid of scripts is to replace them with regular applications. Modern apps have a lot of functionality built in that used to have to be handled by scripts. Consider whether one or more of your applications can replace some or all of your script.
If you can't get rid of a script the next best thing is to move it to an application supported by a vendor. Several firms have many tested, debugged scripts on their websites to work with their applications. It's usually worth replacing a home-brewed script with one of these if possible.
(Note, however, that the notion of “tested, debugged outside scripts” is what lawyers call a “rebuttable presumption.” In the immortal words of the Gipper: “Trust but verify.”)
Simplify, Simplify, Simplify
If you can't completely eliminate a script, look at how you can simplify it by using modern functions in the operating system or applications. One of the major goals here is to make your scripts as simple as you possibly can. But, of course, no simpler.
Try to avoid the tasty hacks and downright kludges that programmers take pride in writing into their scripts. These days they are usually unnecessary and they can be a major headache at maintenance time.
You should also make sure all your scripts are well documented. No one should ever have to wonder in the future what the script does and how it does it.
Better Scripting Through Tools
One change in the last few years has been a huge increase in the tools available for writing scripts. Almost uniformly these new tools make scripts easier and faster to write with fewer mistakes. An example are script creation tools like AutoMate from Network Automation. These tools let users write scripts (mostly in standard scripting languages) more quickly and correctly. AutoMate, for example, uses a drag-and-drop interface to handle most phases of script construction.
In addition to general scripting tools, there are specific utilities for most of the common scripting languages.
Picking Your Candidates
One place to start dragging things out of your script closet is with your Internet scripts. Websites are notoriously script heavy and a lot of those scripts are outmoded, or in desperate need of replacement or rewriting.
With webpages there's a strong tendency to get the thing working and leave it be, no matter how much bogosity is left in the “finished” product. It's worth taking a second look at your webpages to see what can be improved. Pay special attention to errors like using the same script twice in the same page. This is usually the result of programmer error and it can drag down performance of the page.
Take a close look at long, complex scripts. Scripting languages were designed to automate short, simple operations. If you reach the point where a script is working around the language’s limitations in flexibility and power (a discussion that has led otherwise sane people into flame wars, so we shan’t go there) consider whether the script is the right methodology. Often these are jobs that could be done better with an application, often a third-party application. Seriously consider replacing them.
If you can't replace a troublesome script, consider modularizing it by breaking that big honking script up into a series of smaller, more manageable scripts. If you can't do that, then document the heck out of it so everyone knows exactly what it does and how.
The other place to look for improvements is in scripts that drag down performance. A script that uses a lot of resources or otherwise slows things down is an ideal candidate for remodeling or elimination.
Often these are scripts that only run intermittently, such as at backup time or end of the month closing. Because they're not constantly active they tend to be ignored, or their overhead is put down to the underlying job. Still, they can be major drains on performance while they are running.
Closet Cleaning and the Counsel of Perfection
Ideally, you'd go through every script in your organization and replace all the ones that need it. In practice, you're unlikely to have that much time or programmer hours to devote to the project.
What you should do is triage your scripts. Find the ones that look most in need of replacing and start with them, preferably in order of potential problems. It's unlikely you'll get to every single script, but you can usually harvest the low-hanging fruit without too much trouble.
See also:
