I wish everyone reading this could be lucky enough to meet Tim Klein someday. Tim is an incredible writer, an excellent artist (he built an awesome art car) and one of the best software engineers I’ve ever met. I’ve known Tim for 20 years now and am immeasurably better for it, in a thousand ways, big and small.
Tim has an incredibly unusual programming style, one that is probably unique in all the world. When in college, he wrote all of his programs using a notebook. Not a notebook computer – I’m talking about 8 1/2″ x 11″ blank white typing paper. Then, when it was all done, he would go over to the computer and type it in. The weirdest part is that when he was finished typing, the program almost always worked perfectly. On the first run. This is unheard of. I’m an OK programmer, and I’m lucky if it limps along on the tenth try.
Tim’s approach has an unusual provenance (a word I wouldn’t know about if it weren’t for Tim, by the way). When he was in college, they kept the computer room uncomfortably cold. I guess they thought the computers appreciated it. In any event, it was too cold in there for Tim, so when it came time for him to do a programming assignment, he would zip into the computer lab, grab a stack of computer paper, take the stack to someplace warm, and write out the program in pen. He obviously did not want to spend more time than necessary in the Computer Freezer, so it was in his interest to make sure that the program worked on the first try.
Part of the reason I believe this worked so well is that no algorithm could be bigger than one or two pieces of paper; otherwise, it would get unwieldy. This turned Tim into a master of abstraction. And, in software engineering, abstraction is everything.
The Development-Engineering Gap
With robotic process automation (RPA) tools, development is very easy, but engineering is hard. What I mean is it’s very simple to quickly write a solution that does something. But just because you can get the computer to do something doesn’t mean it will do it every time, with all data, in all situations – and when it fails, to fail gracefully.
What I’ve realized from my numerous years in the RPA space is that developers don’t come out of the box knowing how to properly abstract things. Moreover, the industry is growing at such a pace that experienced folks are almost impossible to find. So, we’re left trying to get inexperienced resources to create business value ever more quickly. To make matters worse, these resources are often thrust into engagements that are already in progress.
Elements of a Solution
To overcome this issue, we’ve developed a set of coding standards and design frameworks that enable a developer, after only a few days of training, to drop into an engagement and begin developing robust, reusable solutions, in any compliant engagement, immediately. As an added bonus, the development can be massively parallelized, so you can speed up development simply by throwing more resources at the problem, and it comes with an automated test framework.
Sound fanciful? Let me show you how it works.
The first thing we do is map out each of the applications that we are going to need to interact with. From there, we break the application into what we call “Fractals.” For the purposes of this discussion, a Fractal is “a stable application state.” An example might be a login screen, a main menu for a particular application or the Google Translate page.
There are only two things that we can do on a Fractal:
- Actions: Examples include filling out a form, reading a set of values into a dictionary or data table, clicking and dragging an item across the screen, and so on. Although performing an action may have side effects, it must always leave the robot on the same Fractal on which it started the action.
- Navigations: Navigations are anything that ends the robot off on a different Fractal from the one it started on.
The final piece is the conventions for code storage, variable naming and so on. An application corresponds to a folder in my source repository, and Fractals form a hierarchical structure within that folder. So, the source of the root Fractal of, say, the Windows calculator might look something like this:
Inside this Fractal, there are two sub-Fractals, “Scientific” and “Standard,” and their corresponding navigation XAML files. There is an action XAML called “Calculate,” and then a final navigation called “Up,” which is shorthand for “Take me to the next higher level of the Fractal hierarchy.”
Pay attention to how clear this is. We use naming conventions for the navigations and actions so that it’s perfectly clear what they are and what they do. As a bonus, each individual XAML file can be worked on independently of any other, so you could use four different developers on this Fractal, and get it done in an hour.
Tools to Work Smarter
There’s more to how we do this at Cognizant, including an automated testing framework that spiders the Fractal hierarchy and validates proper system behavior, variable naming conventions and how we give all the XAML files the necessary context so they know what they are working on – but I’ve already gotten a little bit too technical here.
The important thing to understand: However you handle abstractions, give your developers the tools to be great software engineers. They will appreciate the clarity, and you’ll create better, more resilient automations more quickly than you ever thought possible.