What is scripting?
Quick note! This blog post is sponsored by my friends over at ScriptRunner.
When I first got into systems I heard a lot about scripting. For a long time, it was a mystery to me. I never saw anything called ‘scripting’ in the system but the administrators (‘admins’) were always talking about it. Then it got even more confusing after an admin showed me a script, which, to me, looked like highly complex code. Fortunately, he also told me something that really helped me out - it's just instructions telling the computer how to automate a task.
That’s all scripting is - a set of instructions a computer understands that guide it along a process. The process can be simple - add a label when a ticket is created, or complex - copy a range of tickets to a new release when a specific condition is met. A big thing to remember is the computer only does what we tell it to in the script, it can't make a judgment call or change its mind like a human can. Instead, it performs the actions we describe literally, which means we have to be careful when we consider what we want a script to do.
What can scripts do?
Since that day an admin showed me scripting I've used it to automate a wide range of tasks, including things like:
Surveying thousands of managers about where their team works from
Streamlining a recruiting system by automatically generating offer letters
Reduced the number of manual steps necessary to update new hire records
Email me when a system experiences an error or needs help
Sample tickets an agent has solved and send a form to a quality analyst to rate their work, then send those results to the agent manager
Other than my technical knowledge of what's possible and my imagination, I've learned that there aren't many limits to scripting. This makes it both really hard and really easy to think of things I want to script out. It's hard because I need to keep learning more about scripting, how to do it and understand limits, and easy because if I can dream it I can (usually) script it.
Why is scripting useful?
Scripting’s biggest offering is something called extensibility - the ability to expand what a system can do. Typically a system will come with a set amount of features tailored to most use cases. Unfortunately, those features rarely meet every need you might have, which is where scripting comes in.
Scripts offer the opportunity to build new features to meet your needs or to modify existing ones to do things differently. For me, this is an amazing feature, since it allows me to take an existing system that does, say 90% of what I need, and get it to cover 100% (or closer to 100%!) of my needs.
I’ve worked with a lot of teams that suffered by using the system’s default feature. They figured ‘that's just how it is’ and assumed they were stuck with it. Scripting, however, offers you a way to have the system perform a task exactly to your needs. Instead of suffering with a ‘it mostly works’ feature, scripting lets you tailor it to your needs.
How does Jira - and ScriptRunner - support scripting?
The coding language used to create Jira is called Java, and while the nice people at Atlassian have made it possible to write custom plugins in Java via a set of APIs (Application Programmer Interfaces), that is an incredibly complex endeavor. To help simplify things, ScriptRunner uses a scripting language called Groovy to allow admins to more easily work with Jira.
That sounds like a lot of information, but don't worry too much if you don't know what that means. The biggest takeaway is that if you want to automate something in Jira with scripting, you'll need to get Groovy (get it?). Groovy also happens to be what ScriptRunner is built on, so if you have ScriptRunner you still need to get groovy.
(I'll dig more into ScriptRunner and a new, HAPI-er, way to script in the next post)
What should you know about scripting?
There is however, more to scripting than just knowing the language or knowing specific commands. For me, scripting begins when I realize I perform the same thing over and over. When I catch myself repeating the same task (always assigning a specific ticket type to one group, always pushing a release after a specific approval, etc) I ask myself if it's something I could automate.
Making time to identify and think through possible things to automate is a critical step. Many teams rush into automating, only to realize they missed a critical use case or picked an overly complex one. Taking time to consider what should be automated helps avoid those challenges.
Personally, I keep a running list of things I'm thinking of automating. I then make time to review it with my team and pick the highest priority, or lowest lift, ideas. Once we’ve had time to review the list, we pick one or two and then go about planning out what I need to do to make the script work.
This typically takes the form of clearly defining the objective, for example, assigning a ticket to a specific person if it's a specific type, and then listing all the steps needed to do that. For example:
The ticket is created as a ‘bug’ or changed to the ‘bug type
Changed the ‘assignee’ to ‘rob’
Add this comment and @ mention Rob ‘new bug for you!’
Add the bug to Rob’s Kanban board
My goal is to write the steps down so anyone can follow them and get to the right end result. I do this because that is how the script will run - following each step literally - so if a human with no background knowledge can follow it, I'm ready to script.
That is a very simple example, but many scripts will handle much more complex situations. Many times I find myself having to get creative in terms of how I think of the problem. There could be technical limitations to the process - maybe I can't quickly convert all the subtasks to epics - that force me to try something new. Alternatively I may have to consider changing the underlying process to fit into how I can script the solution. Either challenge requires me to get a bit creative in my solution.
Scripting as problem-solving
There is another soft skill I constantly apply when I build scripts - problem solving. This can crop up anywhere, from a bug in my code, to a lack of knowledge about how to script, to an issue with the underlying process. Scripting has taught me to be on the lookout for challenges and to become flexible in how I solve them.
Frequently I’m applying problem solving when I run into a bug somewhere in my script. Many scripting languages are complex, making it very easy to make a mistake (even if you’re an expert!). This commonly results in a lot of time spent debugging (looking for the error). Personally I find this to be an excellent learning experience as I get to dig deep into the issue. Many folks, however, would much rather focus their energy on solving their business challenge - not fighting with a scripting language.
I’ll get more into a HAPI-er way to script in the next post - but keep in mind a large portion of scripting is finding, and solving, problems… not knowing a specific language or technology.
Conclusion
Scripting is a powerful tool that lets us extend what systems are capable of. It not only allows us to add new features and abilities to systems, it lets us address unique challenges our organizations face. It can, however, be challenging to learn, and that can present a big barrier to entry.
Fortunately, there are solutions out there that help make this barrier (at least a bit) smaller. Check out my next post for a solution that will make Jira admins more than a bit HAPI-er…
