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

31–40 of 72 posts

Re: My biggest mistake as an RPA developer

#31

Post by UK-AL »

neves wrote: post #27
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…

Weirdly though. RPA consultants in professional service firms cost more than devs.

Re: My biggest mistake as an RPA developer

#32

Post by ChrisMarshallNY »

The single biggest problem with "citizen developers," is that engineering (as opposed to "coding") requires discipline, and heavy-duty, detail-oriented, follow-through.

That doesn't come in Cracker Jack boxes.

Even if we get to the point where all our code is written by AIs, the requirements will still need to be specified with engineering discipline (so they will look a lot like a coding language).

The ideal concept that CEOs have, of "just make it like I dreamed it" will never happen.

It's a nice thought, but DOA.

Re: My biggest mistake as an RPA developer

#33

Post by dragonwriter »

NikolaNovak wrote: post #14
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…

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…

> RPA sales pitch to executives is "This is not changing your application; this is simply doing what your people are already doing in your application, faster and more repeatable with less errors".

> This is a powerful risk-reduction pitch

Is it? It seems to me a powerful risk creation pitch, where instead of dealing with the process problems that make properly controlled change expensive, you just exploit a loophole in your control requirement that are designed to mitigate risk and implement change with no control.

OTOH, since the pitch is generally to the people responsible for the state of the policies, I guess it is “risk reduction” in that it reduces the short-term risk of admitting the larger error since it enables kicking it down the road a bit, and that is something lots of executives like.

Re: My biggest mistake as an RPA developer

#34

Post by crispyambulance »

wodenokoto wrote: post #6
sithadmin wrote: post #3

Earlier quoted context omitted.

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…

I’ve worked adjacent to RPA and I’d like to think they were saving personnel from the most tedious and hair-pullingly annoying work routines. Not using RPA is like not using macros in your text editor, because they are automating programmers out of work. Some data can only be accessed through a legacy gui and it needs to be cross referenced with several proprietary databases that also can only be accessed through a g…

> Even if you begin migrating these it can take years if not decades. Meanwhile shit needs to be done.

Yep, that's the key thing. The ERP systems which have their tentacles all over every part of the organization make changing stuff out effectively intractable.

I don't know if it's intentionally like this (by design on the part of the vendors) or if it's just a consequence of people being terrified of change.

Re: My biggest mistake as an RPA developer

#35

Post by ChrisMarshallNY »

ethbr0 wrote: post #19
pantulis wrote: post #9

"Native RPA processes are fragile in production" Because business processes are poorly documented. And if they are more or less documented they are executed by teams that need to override the underlying technology when a "corner case" happens. As someone else has said, shit needs to get done. You cannot successfully deploy an RPA project without understanding the business process behind it. And that usually means sha…

Ironically, my experience has been that actually getting an existing business process to some definition of documented is ~25% of the value. It's terrifying how much critical functionality at an average company exists only in 1-3 brains.

> It's terrifying how much critical functionality at an average company exists only in 1-3 brains.

It's not actually terrifying. It's the way that businesses have worked for centuries. There's always a "high priest[ess]" in the woodpile, somewhere, that has "The Keys to the Kingdom."

Most businesses have some form of continuity or recovery plan, but many would collapse, without the Key Player, and they do.

The flip side, is that with the Key Player, they can do very well, indeed.

It's just that Silicon Valley has developed a dread of "The Bus Factor," so we do things like deliberately design shoddy project plans, so that inexperienced, disloyal, transient, teams can run them.

I have looked at codebases that were designed to be implemented by a team, when it should have been a simple, 1-person job. It made the code brittle, overcomplicated, underperformant, and buggy as a rotten log.

Re: My biggest mistake as an RPA developer

#36

Post by Foobar8568 »

UK-AL wrote: post #31
neves wrote: post #27

Earlier quoted context omitted.

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…

Weirdly though. RPA consultants in professional service firms cost more than devs.

Because they add business value....................

Re: My biggest mistake as an RPA developer

#37

Post by Foobar8568 »

ethbr0 wrote: post #18
xorcist wrote: post #16

Earlier quoted context omitted.

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…

No, the pitch is: > automate things in a project/environment/client/process that otherwise would wait until heat death of universe to be automated Which is to say "things no one else cares about or thinks are important enohgh to spend time automating." RPA isn't for major corporate priorities. RPA is for that thing that takes up 25% of a 3-person team's week. Or 15% of every contact center agent's time. Neither of wh…

RPA enables the digital transformation of your company! /s

Re: My biggest mistake as an RPA developer

#38

Post by honey-badger »

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…

Author here. In an ideal firm, where data is handled responsibly, you would not need RPA at all. In large organizations though, data tends to accumulate in monolithic islands that are only exposed to each other with legacy UI based applications. Moving this data tends to make up a large bulk of white-collar jobs in large organizations.

RPA replicates the work that these workers do by automating on the UI of the legacy application and replacing them. It is championed by ambitious business professionals who

1) Don't know that a more elegant solution exists in the traditional IT world

2) Don't receive enough support from the IT org to solve this business problem that is crucial to them.

Therefore, such business professionals collaborate with consultants to spear-head RPA projects in the name of digitization, ushering in AI or similarly varnished back-doors.

However, as long as important data tends to accumulate in disparate islands that IT doesn't have the time to pay heed to, RPA projects will continue to be sold at a price that is a little lower than the salaries of the employees they 'liberate'.

There is, although, another wrinkle to this. RPA is also about democritizing IT by handing (ideally) every white-collar worker the ability to write scripts that can automate pieces of their daily-work. Of course, those solutions aren't likely to be elegant, and their code won't be clean, but since their scope is tiny, that isn't a problem.

Re: My biggest mistake as an RPA developer

#39

Post by honey-badger »

UK-AL wrote: post #31
neves wrote: post #27

Earlier quoted context omitted.

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…

Weirdly though. RPA consultants in professional service firms cost more than devs.

That is a symptom of hype. In the long run, this will change due to commoditization, as I point out in the article.

Re: My biggest mistake as an RPA developer

#40

Post by honey-badger »

NikolaNovak wrote: post #14
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…

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…

All your observations are spot-on. Kudos! You have understood this space much better than most software developers ever will :)

And yes - the exhortation in my article was essentially for RPA developers to max out on the use of the text-based script editor.

Post reply on HN