What is a script?

There is an issue that I have observed at all of the companies that I have worked for so far, the definition of a “script”. Most individuals working as developers or somewhere within a software team agree on the basic definition, a script is, a small program, usually written in a interpreted language and usually written procedurally. However, the bigger issue that I have noticed with scripts is not how they are defined but instead how they are used. There seems to be a wide difference of opinion when it comes to when scripts are an appropriate solution.

Most of the scripts that I have seen written are by employees that I will call “development adjacent”, this includes support, qa, system admins, and in some cases development managers. Development, testing, and deployment are usually all handled by the same person and there are rarely any formal requirements. Because of this lack of process they are often deployed much quicker than standard software and because of the useful features they can provide over time they can become more formalized and incorporated into the deployment or build processes for new machines.

Scripting itself is not an issue, in fact it is incredibly useful when used to speed up a task or make a task easily repeatable. But in my experience, their speed of development and lack of bureaucratic red tape, make scripts really enticing when a customer needs a quick solution. The issue is usually the request comes in the form of expecting the development speed of a script but the reliability of a full blown application that has passed though the development process. What makes this situation worse is usually the employee developing the script has none of the resources available to the actual development team, meaning that to meet the deadlines imposed on the creator corners need to be cut. These time cuts most often come out of testing and documentation, I have rarely seen a script that has any documentation outside of sometimes a usage message.

So the trade off most of these companies are making is short term solutions over long term maintenance. Most of the scripts that I have seen in the wild have been written by employees that are either no longer with the company or have moved on to other positions within the company and are not always available, or even remember enough to answer questions about the script.

I am not sure how this issue gets resolved, maybe more specific rules regarding what gets turned into a script versus what needs to go through the formal development process. But the main issue is the individuals (management) that would need to create and enforce these rules, are the same that benefit the most from scripts. Since scripts are usually created to solve specific problems faster than the normal development process, when they work properly, they make managers look like they have solved a problem faster than possible with almost no resources used (under budget and early).

I have been bitten by this issue numerous times through out my career, I am not sure what the best solution is. I am guessing it has been solved in certain companies, since in large companies a failure of a script would cause much bigger issues. I would be interested to see what these solutions look like if they exist.

-JH