Should SCM Professionals Be Scripting Experts?
A recent question on the Linkedin discussion forum for SCM professionals intrigued me. Someone asked to what degree should SCM professionals be scripting experts? If you didn’t already know, way back when, SCM used to be referred to as a “black art.” Why? Because you had to be a CM guru to keep things together. Scripting is OK. A lot of scripting is not.
As soon as you start embedding a lot of scripting into your CM/ALM solution, you’re telling CM managers that they need to be scripting experts. You’re also telling them that if they want to know the process, they better read the scripts, because we know that the scripts and their documentation, if any, won’t be in step.
Scripting tends to hide process information, and even worse than that, it makes a process difficult to change. Even more worse, it makes process automation less reliable when a process is changed. Chaos can appear when there is a simple scripting error or logic error in the scripting.
But not all scripting is bad. What you really need is very high-level scripting with one to three lines that accomplish a specific purpose, such as retrieving source code, producing a report, or protecting an operation (i.e., a rule). If your scripting isn’t high level enough to do this, you’re in trouble, and most tools and scripting languages can cause trouble!
But it is possible to do high-level scripting. As I described in my CM Crossroads article, "The Next Generation of ALM Tools," you can create byte-size scripts that do a specific function like implementing a menu button, defining a dashboard, or defining a to-do list or a report.
In the early 1990s, CaseWare/CM was the forerunner of Continuus, the forerunner of IBM’s Rational Synergy. It was heavily scripting oriented—too much so. It repackaged itself to hide most of its scripting and became a viable product. STS, the forerunner of Neuma’s CM+, also relied heavily on scripting. It focused on making its scripting very high level, and it became a viable product.
What about scripting in order to pull tools together into a full ALM solution? Is that OK? Well, if you can pull in a tool with a snippet of scripting, that’s fine. If you have to build an intertool interface, forget it. Find one, buy one, or better yet, get a full ALM solution that’s built on a single set of infrastructure (i.e., DB, Admin, Process, GUI, Customization Capability, etc.).
To do otherwise, you’re hiding your process restrictions. For example, you might not be able to perform a specific task because tool A doesn’t let tool B see that information, or tool A’s process model is in a language different from tool B’s. You have to look inside the scripting to see what you can do.
In the end, a solution with very high-level scripting requires little training, but it requires expensive, trained consultants. While high-level scripting for SCM professionals is great, you might need to rethink your technology so your CM team can do real work.
