This script development process is an iterative process designed to help you rapidly write quality scripts. The principle is to understand and define the problem. Break up your solution into small steps. Code one small step at a time. Test each small step and get it right before moving on to the next piece. Repeat these steps until you have your solution. All while managing your time.

When is automation the solution?

The benefits of automation are primarily to save time and to decrease errors associated with manual actions. You will need to make the calculation if a script will benefit your situation. How many hours will it take for you to write these script? How many hours of manual work will the script save?

Suppose you need to install an application on one server, rarely to do it again. Not much benefit of automation in this case.

Now suppose for an example, you need to install the application to one hundred servers after hours. Suppose it would take twenty minutes to manually log in, launch the executable, wait for it to finish, check for errors, then log out. That works out to more than thirty-three hours total for one hundred servers. Let’s say it takes you four hours to manually install to one hundred servers. You could probably write and test this script in four hours. Spend four hours to save thirty-three? Sounds good to me. And now that you have that script, you can recycle it for the next time you have a similar task. Automation is looking a lot better for this case.

Problem (or) Task

The “problem” (or task) often comes as a vague request or is poorly defined. Or maybe you noticed a task that you can automate to save time. Whichever way the task comes to you, think of it as a puzzle to solve.

Understanding the problem

Get the details of the task from the requester. What do they want? What result do they expect? Who, what, when, where, why? Ask questions. Really understand the request. Sometimes the requestor doesn’t fully understand what they want, so you may have to work with spotty information, or even wrong details. It’s your job to figure it out.

Even if you are the origin of this task, you need to fully understand the problem.

You might find out that this is not really a problem, that the situation is necessary for security, legal reasons, or something else. You might not be permitted to “fix it” with a script.

Does your company own a tool that can or should do this task instead? Use the right tool for the task. PowerShell might not be the right tool for your task. For example, if your company has Microsoft System Center Configuration Manager, that would be a better tool to do mass installs than a standalone script.

When new information comes to light, at any stage, re-evaluate your understanding. Document the problem.

Understand the solution

Now that you understand the problem, hopefully the bones of a solution are coming to light. Roughly, decide what kind of solution you will provide. Document the intended solution. It’s also important to note that you should limit your solution to the problem at hand! Don’t over-engineer a solution. Your time is valuable; don’t waste it. An over-engineered script is also more difficult to test and troubleshoot.

Consider if this will be a large effort (more than twenty hours), you may want to break this into several solutions. A partial solution might help right away. Later, you can augment it, making continual improvements. To follow the example of installing software: A script that remotely installs the software to one computer at a time would be better that manually installing. Not as good as full automation, but an improvement.

Divide and conquer

Now that you have a solution in mind, divide it up into bite-size parts. Maybe two parts. Maybe five parts. If it’s a really big task, break it up into major “parts” then divide each part further, into a hierarchy, or a tree, of parts. Ideally each part will be small, either one or a few lines. Usually not more than twenty-five lines. Each part should do one thing. It should be small and simple. Each part should be testable. You might know not how to break it all up at first. As you work on it, your path will become more evident.

Code 1 piece

Start with the core of your solution. The most basic part, if you have defined it that way, to prove that your solution is the right one. If the one piece can be a function, do make it a function. The function should do one thing. If your function is running longer than twenty-five lines, is it really only doing one thing? Consider making multiple, short functions. You’ll find that short functions are easier to understand, test, and troubleshoot.

Test

Test your solution, in a safe manner. Safe? Test in a lab or dev environment, especially if your script changes anything. You can’t allow your script development to cause problems. How embarrassing that would be. If the part you are testing is small and simple, and better yet, a function, testing should be easier. If your task is fully defined, and your solution is fully defined, and your code is simple, the results of your testing should be clear.

Functions are usually easy to test, as they take well defined parameters and (usually) return a value.

Test with good input and bad input. Is it the result you expected? Does your code handle the bad input correctly? Does your code fail gracefully and clearly? Success or failure should be clear. If the code test was successful, code the next part of the puzzle. If the code test was not successful, or you uncovered something that you didn’t realize earlier, then reevaluate your assumptions. Reevaluate your understanding of the problem and the solution. Do you need to change the basic solution? Or was it a simple typo? Go back over it, and then test again.

Is there more?

Keep working on the parts and build up your solution, testing frequently along the way. As your understanding changes, adapt your solution.

Success!

Finally, you’ve got it all working. Congratulations. If this is a frequently used script, you might find value in reevaluating it later and perhaps making improvements, if you feel there will be value in that.