What do we do with our RPA Developers?

An Interesting Experience

So let’s talk Robots, RPA, Robotics etc. There are a lot of names and a lot of people talking about it. Few developers are talking about it though. There is hype amongst executives, and amongst the consultancies that provide this service.

Every day on LinkedIn I see a different ‘report’ and a different company popping up that proport to know everything about it. I have worked for a lot of these companies myself. Ok, so lets rule out the large players in the U.K for the purposes of this discussion. These are:

• GenFour
• Symphony
• Accenture
• Etc.

Most of these guys are well seasoned in development and have been dealing in software for sometime. I am not talking about these guys.

So who are the rest? We have a situation where people are writing papers on RPA who have no clue how to develop it. Essentially relying on outsourced devs to get the job done whilst paying little to no attention to how it is put together, or more importantly how stable and secure their robots are.

How many of these guys have checked if current viruses affect their bots?

MY EXPERIENCE

Let me tell you a story. I left one of the larger companies and went to work on a consultancy basis. I interviewed for the job, and then was asked if I had any questions. I asked what deployments they had worked on. I was told it was an emerging market and that they were mainly working on research. Now, research to me in my naivety, I took to mean in the academic sense. I assumed they meant they were testing different vendors, security and scalability. They were working on a POC for a large company.

Off I went to the company they were working for. It didn’t take long for me to realise this was a clean-up operation, and this wasn’t a POC. This was a bot that that had a production deadline.

There were four Analysts and one developer. I set to work.

The current build I got was a simple click and type operation. I was alarmed to see the development plan was to run this commercially on a low spec laptop, using free to download software that was unlicensed. It was to take an excel spreadsheet each month and translate the data before entering it onto a live system. There was no underlying database to hold or queue up data. No error handling. No logging. It couldn’t run headless. No security analysis. No disaster plan. No development standards.

You can see the problem, even if you aren’t a developer. This isn’t a robot. This is a dangerous babysitting exercise. There was no design document. Actually I tell a lie. There were tonnes of documents. Analyst documents.

So, I started to get it together and give my opinion. I said that I believed we needed to start again and put off this deadline. The design document needed to done and the proper architecture needed to be put in place. This was never going to work. Let’s catch our breath.

I was told that it was fit for purpose, and that I needed to put up or shut up. It didn’t need any of this- it’s a POC.

To cut a long story short- I should have got out then. Instead I began to fix it. Lots of hours and lots of ‘meetings’. I was in an average 4 hours of meetings a day. That’s half my working day. Let me clarify. These were not developer meetings. I didn’t say much, I listened while these guys talked about RPA and told the client what the software most certainly could NOT do. How safe it was and how it would save them so much money. I cringed a lot, now and again correcting terminology. At one point they wanted the robot to start dropping data directly from a production database with one day of testing.

It dawned on me these guys were under the impression that the software automated the build.

I realised my opinion counted for nothing. So the build went on. I worked mad hours. We got it done and ready for testing. Testing was fudged.

I suggested a phased introduction. Let’s do 100 cases and verify them. I was told no, we had to do the full case load in production. 1000’s of line items, with no proper logging. Everything done in memory, with no error handling. So if a crash happened we had no idea where it happened, and could restart it at a waypoint.

I said there was no way the bot could get this caseload done in time on one laptop. The answer was to do it on several laptops. With no database, you can’t distribute it. So we cut the large excel seed data up, and gave it out to everyone to run overnight. The guys running it had no idea how this software worked or how the build was done. They hadn’t taken the time to understand.

Off it went. That night I stayed up all night watching and restarting the bot. Manually checking each one to make sure it didn’t do anything crazy.

The other guys all started theirs and went to bed. Well you can imagine how that went. The clean-up operation happened, and off we went again. This time I took the laptops, three of them, and did it myself. I spent a few days each month for about six months staying up all night making sure the bot ran O.K. I was given no time to fix it properly.

Needless to say, we all fell out and it was an all-round horrid experience for all concerned.

I am going to detail here what to do with your developer(s) to make sure you don’t have that experience, how we do things at Sonix and ways to ensure your robots and devs are happy.

Before we Begin                                              

Let’s pause for a moment and consider something. In layman’s terms, how does RPA software work?

My first I.T. project fresh out of Uni was Y2K. The next one at the end of January 2000, was automating an old mainframe in a Bank. Since computers have been around, so has this. All of a sudden we are calling it something different.

The whole point of most software is to automate a task, making it easier.

My first program was on a ZX Spectrum, and it was to write funny things on the screen. Is this not automation? I used code to take over the keyboard. There was no mouse back then, but if there was, I would have been able to write code to take that over too.

You get my point, it’s been around a long time. Writing code to take over the hardware and other drivers has simply evolved in the same way as other aspects of computing.

RPA software is awesome, don’t get me wrong. It’s the code we used to write packaged up so that it is easy and quick to write it.

There are some misconceptions.

1. The build is automated
2. There is no dev lifecycle
3. There doesn’t need to be as much testing
4. Any system is suitable for automation
5. Anyone can do this

The developer

The developer is a strange creature. Very complex in some aspects, very simple in others. The funny thing about them is that they will do exactly what you tell them.

We were moving office recently. I was packing everything up to go, and I asked one of my devs to ‘take his desk down and get it ready to go’. By this I meant put his stuff in a box, and clear off the desk. I went off to do other things. When I came back he had gone out to get a screwdriver and literally taken the desk and chair apart and neatly popped it in boxes. Ready to go.

Did you ever play Lemmings? If not have a look at this link-

www.elizium.nu/scripts/lemmings/

You control the little guys and they go over obstacles and you need to keep them alive, because they will only do what you tell them.

A lot of companies talk about a ‘no blame culture’. I run a software house and only employ developers. I have learned over the years that you can’t ask the developer to invest their time to do something with no definition. They will interpret things differently like any human being. And make no mistake they are human. And you can’t just blame the guy that built it when things go wrong.

The developer is no different.

HOW SONIX OPERATES

I have a rule here, 9-5 with an hour for lunch and a 15 min break either side. Trust me, this will save a lot of trouble in the long run.

A few reasons for this ‘rule’ include:

1. The staff are the most important part of the business. You train them, and you really want to keep them. If they aren’t happy, they will go elsewhere. You will then have to invest time in training more staff, only for them to leave and you are in a cycle.
2. What I call the ‘wood for the trees’ situation. The developer after 8 hours, will not be able to solve problems- only create new ones. I have spent many nights poring over code to try and figure out where a bug is. I give up very late, and begin again in the morning only to fix it after 10 minutes. This is a very common occurrence amongst developers. I now make sure I approve any overtime, to make sure it is completely necessary, and sometimes, to be fair, it is.
3. No man left behind! Or woman for that matter. One company I worked for used to leave me to fix things while everyone else went home, then gave me grief when it wasn’t done in the morning. I ended up getting up one day and leaving, never to come back after sending a very scathing email to the boss. If our staff are having problems, I stay as well. Even if it’s just to make the tea.
4. Finally, you may want someone with experience in two areas, but don’t expect them to teach themselves in their own time to do something they have never done before.

These are professionals who know what they are doing but need direction- like us all. 

Click the robot to find out more about Sonix Software.