Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

My biggest mistake as an RPA developer

anupam.de

Post reply on HN
Print view View original

21–30 of 72 posts

Re: My biggest mistake as an RPA developer

#21

Post by ethbr0 »

wodenokoto wrote: post #17
netizen-936824 wrote: post #12

Earlier quoted context omitted.

Increasing interoperability sounds like a good reason to move the data to things that don't use GUI only proprietary interaction, rather than a good reason to throw some duct tape on. But that takes actual work

I don’t think even the RPA department will disagree on that one. But while the 3rd 100million project to rewrite that legacy, proprietary cobolt data app is faltering, the RPA department is actually making it accessible via a rest api that activates a virtual mouse that clicks around and ctr+c,ctr-v the result back to the user. The curse of building great digital infrastructure in the 80s is you might get stuck with…

Also, and I think this is underappreciated by the HN crowd, because they don't work at these types of companies -- interfacing with legacy business-critical applications.

Most software products that companies buy have interoperability as either the least prioritized feature or as something to be actively prohibited.

The best, brightest, most modern examples of software, we are not talking about.

Re: My biggest mistake as an RPA developer

#22

Post by Bouncingsoul1 »

xorcist wrote: post #11

Please explain to me what the use of RPA is. Here's my background in the subject: I have met with team of a dozen people that spent half a year doing something that turned out to be the functional equivalent on an SQL one-liner. They could not within our meeting slot accurately describe what it is they were doing, apart from "automating tedious work" (yes, but what is that work, specifically?) and kept insisting I wa…

Hmm they only context I know it is in context of test automation as "Hardware in the loop". Apply nightly firmware to ble-perpheral via ssh- Install nightly app build on mobile via adb- Test ble connection - Test ble bonding- Test interaction between the devices- control some relais to trigger certain events- curl to see if events land in backend....

would be tedious to do it manually. That said everyting is in git...

Re: My biggest mistake as an RPA developer

#23

Post by ajcp »

"Most native RPA automation is GUI based. But let us take a moment so that this sinks in. GUI based automation involves instructing a bot to communicate with another program via the UI. This is analogous to forcing two native speakers to communicate via charades. GUI based automation is always a compromise because there is invariably a more efficient way to perform the same task under the hood. This brings me to my second reason."

The author isn't very clear here and seems to be themselves unclear on how these RPA technologies actually "see" an application.

Every Robotic Operating Model I've ever seen or worked on has always held firm that "surface automation" (think Citrix Receivers and applications built in Silverlight or Flash) should be outside the scope of any RPA solution.

What's left are browser or desktop based "physical" applications that actually have an underlying model used to describe and render a GUI. This is actually what is being utilized by (most) RPA clients.

While correct that the clients do interact with the UI of a program, depending on the application they actually interpret (or "see" it) via the application COM (component object model), or in the case of a webpage, the DOM (document object model). Since these are essentially used to describe what is rendered on screen -usually in a more detailed way then what is actually rendered on screen- the RPA client is able to efficiently and confidently interact with the application.

Take a webpage with a red button to click for example:

Automating purely via UI/surface automation: - Capture 150px by 150px at screen coordinates x and y - Is captured image red with the words "Click me" on it? - Go to x coordinates on screen - Go to y coordinates on screen - Send key 'Right mouse button click" - Pray

Automating via DOM: - Attach to process `Chrome titled "My webpage"` - Is element `Click me` present? - (to browser client) Send key `Right mouse button click` to element id = "superUnique_superDependable" - Wait for process `Chrome titled "My other webpage"`

OR

Automating via DOM: - Attach to process `Chrome titled "My webpage"` - Run function `navigate(MyOtherWebpage)` - Wait for process `Chrome titled "My other webpage"`

Re: My biggest mistake as an RPA developer

#24

Post by NikolaNovak »

xorcist wrote: post #16
NikolaNovak wrote: post #14

Earlier quoted context omitted.

Sometimes it's the unobvious, non-technical things. FWIW: In my world, we have native tools and methods as part of our ERP application, that would accomplish certain automation tasks more efficiently and effectively than RPA. But that would constitute a "change of application" (because it would be); change management and sign-off on these is so onerous; and the perceived risk and potential impact so high; that they n…

So the pitch is that change management hasn't caught up with them .. yet. The very second one of these runs has some non-intended consequences, and from the nature of the tools that's likely to happen sooner rather than later, change management will latch on to them and never let go. The tools in question were very similar to Selenium. Any non trivial job is going to have logic in it. Definitively not any less progra…

ethbr0 provided valuable perspective, but just to respond:

1. I've updated my post to make it more clear how change management is involved: Using native tools we would be, literally, "changing the application". RPA is not changing application; it is automating what people already do in application. It can get philosophical whether this is a real difference or semantic one; but in corporate world, it's real :). And ultimately in techie world too: ERP is not touched or customized by the RPA (which would have had meaningful and permanent repercussions for troubleshooting, vendor support, upgrades, retrofitting,etc). On Ops side too, we use same process and tools to troubleshoot an error in our application whether a human or RPA bot did it.

RPA bots still go through change management as such; but their risk, cost, implementation time and other profiles are simply vastly different than actually touching the COTS ERP application code. I would not necessarily use RPA to change most of the applications internally made by a company; but they're a valid choice for automating a externally sourced software.

2. I have limited experience with Selenium but I would agree that there are broad similarities. They even remind me of old Mercury/HP LoadRunner or SQA Robot. Just, couple of decades of advancement and different focus.

3. I feel "Clearly intended for a Microsoft focused audience" is some kind of insult, and somewhat uncalled for; but note our application runs on AIX on p-Series, FWIW.

Re: My biggest mistake as an RPA developer

#25

Post by dfxm12 »

xorcist wrote: post #11

Please explain to me what the use of RPA is. Here's my background in the subject: I have met with team of a dozen people that spent half a year doing something that turned out to be the functional equivalent on an SQL one-liner. They could not within our meeting slot accurately describe what it is they were doing, apart from "automating tedious work" (yes, but what is that work, specifically?) and kept insisting I wa…

It's supposedly a "citizen developer" tool that records your actions, as a macro, and runs it later, so all those executives got it in their head that if they buy RPA tools, they won't have to spend extra on developers for automation tasks, but then, people decide they don't have the time, wherewithal or just think it is beneath them to learn this stuff and end up hiring "pro" developers to do it anyway, so it usually ends up becoming just as expensive to build and maintain, and usually nowhere near as robust.

If you really do have citizen devs in your org, it's great. I think people are more willing and able to learn Power Automate for Desktop than PowerShell/Python/what have you, then add in the governance, inventory and monitoring/analytics options in an RPA tool like Power Automate, and it can be easier to manage.

Re: My biggest mistake as an RPA developer

#26

Post by icecap12 »

I'm not knowledgeable on the topic of RPA, but it has always felt to me like RPA was nothing more than a trendy scam. I suppose there must be some value to it under the right circumstances, but how it went down at my last company influenced my pessimistic view.

Anyway circa 2016-2017 at this $BIGCORP, somebody got excited about RPA, created a lot of buzz with the executive team, and secured funding to build an entire RPA department.

Everyone was was excited! People were speaking at conferences after 6 months of scripting, grand claims of thousands of hours of work being eliminated were made, and so on. 2 years later, the entire department was gone. I never met anyone there who actually had work eliminated by the so-called RPA scripts...so it just felt like a big joke to me.

I imagine there are people who have had good experiences, but I've not really heard of them. I'd be interested to hear of legitimate benefits in this space.

Re: My biggest mistake as an RPA developer

#27

Post by neves »

xorcist wrote: post #11

Please explain to me what the use of RPA is. Here's my background in the subject: I have met with team of a dozen people that spent half a year doing something that turned out to be the functional equivalent on an SQL one-liner. They could not within our meeting slot accurately describe what it is they were doing, apart from "automating tedious work" (yes, but what is that work, specifically?) and kept insisting I wa…

The use of RPA is to allow companies to contract cheaper people to do development job.

Every 10 years or so you will find the industry trying to sell GUI programming tools. Managers will love it. It will sell a lot. Then people will start to see the brittle applications, that it is impossible for 2 people to develop at the same time, that you can't see what changed from 3 versions ago etc.

Then you will have to point your manager to the the 1986 article "No Silver Bullet": https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&c...

Re: My biggest mistake as an RPA developer

#28

Post by jerf »

sithadmin wrote: post #3
mgkimsal wrote: post #2

RPA is "robotic process automation". The author worked with the uipath.com platform, which looks to be an automation tool to click on screens to automate processes (probably oversimplifying here).

You're not really oversimplifying. RPA is duct tape for situations where it's drastically cheaper to automate personnel doing repetitive tasks out of work and have a fraction of the original team supervise a fleet of(rather persnickety) 'bots' that insert keystrokes and clicks in a legacy application, as opposed to building proper systems integrations or rebuilding the underlying legacy app entirely. I understand the…

"as opposed to building proper systems integrations or rebuilding the underlying legacy app entirely."

Spinning the blame around a bit, I've often thought that part of the problem is we keep building GUI toolkits that hate this usecase. If they supported this better, the RPA stuff would be less awful.

Appletalk almost did it, but my impression is that it is dead now.

Websites have decent support for it, but trying to use it in practice still involves a lot of little compromises everywhere. It still breaks pretty easily, and the workflow is bad even when you learn all the tricks.

But there's a lot of useful code buried in GUIs. If there was a way to write scripts against the UI, in a discoverable, testable manner, this would be a much more sensible strategy. And you wouldn't necessarily have to hire developers just to maintain a "real" solution.

But we persist in treating this as a fifth-class citizen in our widget sets, so... here we are.

I mean, yeah, it would always be a bit of a tech debt pit, but it doesn't have to be anywhere near as bad as it is now.

Re: My biggest mistake as an RPA developer

#30

Post by jerf »

This is part of why you want to be "T shaped" and not "I shaped". It helps give you perspective on the context you're in and make sure you're not making really unfortunate mistakes just because you only understand your small part of the world.

It'll even make you better at your main skill. There is some progress you simply can not make if you never leave a singular frame of reference.

Post reply on HN