Hacker News Reader

Comment by honey-badger | Hacker News Reader

Author here. I agree entirely with what you say here. But consider this. I once automated an RPA process to create service records for the customer service department. I did this by automating over a Java based UI app, with reliable selectors as you correctly point out.

However, that app's UI would keep changing due to updates from the IT department, over which the customer service department had no control over. This is why I call the automation 'fragile'.

But if you are automating using a bot (a software program), why does it not have access to the same pool of data as the UI application (some database somewhere)? Would that not be a more robust means to retrieve it rather than via the UI?

If you are automating a business process via the UI (other than for simulating user interactions for testing) there invariably exists a more efficient way to achieve that end without involving the UI. I have found no exception to this rule.

View on HN

True, there is (hopefully) always something like a DB on the other end, containing the data in a a fashion that makes it much easier to operate on (sql).

But is that really RPA at that point ? Suppose your task is to scratch some data from a website, calculate something and if some condition is true also perform some form submit.

If you do have access to the actual database you can just use that. If you also have access to the API of the system, you have to "check some box", you might as well just write a normal application that calls some SQL, perform some http-posts and maybe also provides a nice website with that data it crawled, formatted in the way you wanted to calculate the data, in, let's say excel. (Some would say you wrote a microservice.) And if all of this is possible then you're apparently good enough in programming that such a solution is the way to go.

But if you're in the typical corporate environment where the API doesn't exist / you can't access the database / you're not allowed to interact with the checkbox except for the proprietary application, then you're back to what an RPA was supposed to do.

Because otherwise we're down to one question: When is it an RPA ? When you're just using a fancy UI ? When you're not accessing any API ? When you don't script ? Or is the example above with SQL + API also an RPA ?

RPA to me rings "mouse recorder for dummies" or "ugly hack that breaks depending on how good your visual detection system is". At least when you described discovering that you can actually just use real scripts instead of UI indirection, it reads like something like that. A "not invented here syndrome" of that RPA tool, instead of a helper that handles checkbox-detection + clicking for you.

Well, the truth is that developers often underestimate how hard it is for non-developers to write scripts. The reason why they don't understand why something like RPA exists is also known as 'The curse of knowledge'.

I think you're totally right. I could write a lot about this divergence between knowing how the technology works and trying to get something done with the limited tools or time you have. But essentially you're right.

Also that auto-hotkey script for automatic driving in GT is really impressive. ( https://github.com/ByPrinciple/GT7-Scripts/blob/main/PanAmer... ) So that's something between scripting and RPA. Essentially a DSL for exactly this task, which totally destroys my point. And does make a case for learning how to script with a tools that's capable enough, that it is useful for more than the best case.

Reply on news.ycombinator.com