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

Microsoft's low-code strategy paints a target on UIPath and other RPA companies

infoq.com

Post reply on HN
Print view View original

171–180 of 198 posts

Re: Microsoft's low-code strategy paints a target on UIPath and other RPA companies

#171

Post by Mister_Snuggles »

jwally wrote: post #160
Mister_Snuggles wrote: post #119

Earlier quoted context omitted.

In my experience, the lifecycle is more like: * Person in the business area implements RPA. Business area is happy. * Person who implemented RPA moves on to greener pastures. * RPA breaks, business area calls IT. * IT is horrified at the unsupportable mess that's just been dropped in their laps.

1000% this. I’ve seen it happen with excel, access sql-server; and RPA. Some some Frankenstein’s monster is cobbled together to solve a problem whose best solution would be “stop producing the report that nobody looks at” only to have it slowly decay out of orbit. The other major flaw with RPA is non-engineering LOB employees (in my experience) are incredibly myopic and implement solutions to get shit done now withou…

Sometimes the solution is also "Get IT to fix the thing that you're working around"

There was a delivered process to do a particular job, but it didn't work. Nobody thought to tell IT that it didn't work, instead they built a Ruby+Selenium script and ran it on a spare computer. Which worked great until it didn't.

Re: Microsoft's low-code strategy paints a target on UIPath and other RPA companies

#172

Post by ayewo »

rchaud wrote: post #49
syshum wrote: post #10

Low Code is the modern version of "Write Once run Anywhere" It is pipe dream that will cost companies millions in Vendor Lockin, rewrites, and all of the other problems that come with non-developers "developing" See the nightmare that is Excel Workbooks, the fact they are modeling FX on Excel Function is a horror I do not even want to think about

My university's application system is a set of workflows based on drag and drop Salesforce components. It processes tens of thousands of multi-step, multi-page applications without any issue.

> My university's application system …

Application system? Perhaps you meant admission system?

Is there publicly available info where one can read more about it?

Re: Microsoft's low-code strategy paints a target on UIPath and other RPA companies

#173

Post by golergka »

dnndev wrote: post #55
golergka wrote: post #29

Earlier quoted context omitted.

Isn't that survivorship bias in action? Good solutions that not only work, but work well and don't hit the tech limitations would never be seen like developers like you, because they would never need to be rewritten.

I am not sure how this comment contributes to the thread. It is a bias because I write my real-world experiences? What you are saying is true for so many things. Car that does not break does not need a mechanic. Of course, and nobody is disputing that. This comment just made me laugh so hard I had to reply.

I apologize if my comment upset you or was offensive to you in any way. I only meant to notice that your comment paints a picture of all such projects being awful, and this may not be a faithful representation of reality.

If you didn't mean to paint such a picture, I'm sorry for misunderstanding.

Re: Microsoft's low-code strategy paints a target on UIPath and other RPA companies

#174

Post by trixie_ »

filoeleven wrote: post #113
trixie_ wrote: post #94

We really need a revolution in the low code space. The amount of code we write - database, backend, api, frontend, etc.. to do the simplest CRUD task, makes me feel like compared to future programmers we're all cavemen rubbing two sticks together.

Better tooling for data-oriented interfaces is the answer. Everything CRUD does is at the interface layer. If you improve the semantics and discoverability of the interface, you enable better tools and products to grow from that. https://www.destroyallsoftware.com/talks/boundaries This talk encapsulates (heh) a lot of the ideals that I agree with. Strong guarantees at the interface layer are good, and foster better t…

Not sure what this has to do with the immense amount of code that needs to be written across various layers in a stack to do the simplest task. Can you translate this into some real and actionable?

Re: Microsoft's low-code strategy paints a target on UIPath and other RPA companies

#175

Post by mgummelt »

ethbr0 wrote: post #164
mgummelt wrote: post #140

Earlier quoted context omitted.

How is legacy compatibility a moat? Any RPA engine, certainly Microsoft's is going to cover the same stack. That's one of the consequences of RPA - when you integrate at the UI layer, you get compatibility for free.

"Integrate at the UI layer" is a can of worms. In simple cases, it's clicking a button. In real practice, it's triggering some esoteric sub-event the developer hooked, or returning coherent data tables from whatever not-table thing a developer cobbled together. Example from current work (US government system, Oracle Forms / Java based): a scrollable "grid", actually composed of individual, carefully-lined up text box…

I'm not saying integrating with UI layer isn't fragile. I'm saying it doesn't offer a "moat".

Re: Microsoft's low-code strategy paints a target on UIPath and other RPA companies

#176

Post by mgummelt »

m1sta_ wrote: post #154
mgummelt wrote: post #140

Earlier quoted context omitted.

How is legacy compatibility a moat? Any RPA engine, certainly Microsoft's is going to cover the same stack. That's one of the consequences of RPA - when you integrate at the UI layer, you get compatibility for free.

Most of them look for window events. I've not seen an RPA tool that actually reads the screen like a human, even though that's how you're thinking about it.

That's not how I'm thinking about it.

Re: Microsoft's low-code strategy paints a target on UIPath and other RPA companies

#177

Post by ethbr0 »

mgummelt wrote: post #175
ethbr0 wrote: post #164

Earlier quoted context omitted.

"Integrate at the UI layer" is a can of worms. In simple cases, it's clicking a button. In real practice, it's triggering some esoteric sub-event the developer hooked, or returning coherent data tables from whatever not-table thing a developer cobbled together. Example from current work (US government system, Oracle Forms / Java based): a scrollable "grid", actually composed of individual, carefully-lined up text box…

I'm not saying integrating with UI layer isn't fragile. I'm saying it doesn't offer a "moat".

My comment wasn't about fragility, it was about how compatibility was long tail.

And long tail, accreted one weird customer at a time things are definitely a moat.

Re: Microsoft's low-code strategy paints a target on UIPath and other RPA companies

#178

Post by [deleted] »

AtNightWeCode wrote: post #157
AtNightWeCode wrote: post #75

Earlier quoted context omitted.

You get Teams accounts with pretty much any MS thing. Teams still can't be used for chat in enterprise environments. It is laughable.

Some MS person down voted this I guess. :) I have Teams accounts in at least a handful of tenants and it does not work for chatting.

[deleted]

Re: Microsoft's low-code strategy paints a target on UIPath and other RPA companies

#179

Post by bsg75 »

AtNightWeCode wrote: post #75
ARandomerDude wrote: post #57

The most mind-blowing part of the article was the Teams vs Slack screenshot. https://res.infoq.com/articles/cloud-vendors-low-code/en/res...

You get Teams accounts with pretty much any MS thing. Teams still can't be used for chat in enterprise environments. It is laughable.

I'm using Teams in a 10,000 person company with employees and external collaborators. Its our primary chat tool, and its used regularly for presentation broadcasts of over 250 people. Is this Enterprise enough?

Re: Microsoft's low-code strategy paints a target on UIPath and other RPA companies

#180

Post by WorldMaker »

mgummelt wrote: post #151
WorldMaker wrote: post #147

Earlier quoted context omitted.

Having done more than my share of coding in VB3-6, I can tell you that VB in any incarnation has never been "low code". If you think that WinForms or XAML in Visual Studio is any less RAD or somehow "more code" than the VB<=6 IDE, you are wearing some amazing nostalgia goggles and I wish I could believe in a world you seem to think existed.

Low code just means using visual techniques to replace or augment code, so any WYSIWYG system, including VB or XAML, qualifies.

No, that's what "RAD" means. "Low Code" means systems like Excel where "formulas" aren't exactly seen as "code" and nearly everything can be wired up visually. Power Apps and Power BI are "Low Code". Access and Excel are "Low Code". VB was never "Low Code", it was "RAD".

(And yes, today's WinForms and XAML editors in Visual Studio are quite "RAD", and exactly as "RAD" as VB <= 6 was, if not more so. VB.NET was never less "RAD" than VB <= 6 from the standpoint of visual tools. It just shifted component/plugin ecosystems and left an impression that it was less "rapid" to develop with because of sharp new learning curve, but the "rapid" never meant "no learning curves", it meant WYSIWYG designers, which VB.NET still had in spades.)

Post reply on HN