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

71–80 of 198 posts

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

#71

Post by pjmlp »

jlarocco wrote: post #36
dnndev wrote: post #6

This is addressing a market. I have seen it first hand more than once. Highly driven and competent individuals that are not programmers for whatever reason and that create a monstrosity that works (using some low code solution). It’s ugly and buggy but gets a job done. This works for as long as they don’t hit a technical limitation then call devs like myself in to replace it. It was a great phase 1 and made money. Th…

"Low Code" is a new (to me) buzzword, but Microsoft has targeted that niche for a long time. Specifically I'm thinking of the older Visual Basics (3-6) and the advanced scripting and database features in Office.

I have seen first hand on some lifescience consulting gigs how VB.NET takes away people from R, Python and similar tools.

It is the Excel experts that have outgrown the macros and VBA capabilities, and get IT to install Visual Studio with VB.NET on their computers.

They then double down on their VBA skills and somehow get to produce something in Windows Forms, or an Excel AddIn for the task at hand and then get going with the actual work.

Then one lands on the lab and it is full of such small utilities.

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

#72

Post by iudqnolq »

fartcannon wrote: post #67

This is the kind of article that I believe would benefit from authorship identification/stylometry. I would like to know how much of the conversation occurring in this comment section is real, and how much of it is part of the recently revealed work that Microsoft has being doing in swaying opinion on hacker news. Wouldn't that be an interesting tool for press releases like this?

> it is part of the recently revealed work that Microsoft has being doing in swaying opinion on hacker news.

I'm deeply sceptical this is real because the risk would be high and the reward miniscule. Source?

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

#73

Post by pjmlp »

brixon wrote: post #38
jeff-davis wrote: post #24

Does SQL qualify as Low-Code? A lot of technical non-programmers are very successful using SQL.

Yes since it is describing more what you want and less how to do it, but SQL is not an end-to-end solution.

Pure SQL no, but when coupled together with language extensions and frontends like APEX, it surely is.

I have seen departments fully managed with APEX applications.

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

#74

Post by syshum »

haswell wrote: post #33
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

> will cost companies millions in Vendor Lockin, rewrites, and all of the other problems that come with non-developers "developing" What many folks miss here is that companies still willingly proceed despite these drawbacks because of the value that the end result provides. These tradeoffs are often less apparent when coming from a software development background or working for a company that builds software. But if…

I agree somewhat, the problem with "business outcome perspective" likely means very short term thinking, get it done now, deal with the rest later.

The people that cause the mess are not likely the ones that have to clean up the mess, people like me are. I prefer to greenfield things but instead I spend the majority of my time untangling the bad choices people made years before coming at it from a "business outcome perspective"

There should be some kind of middle ground, likely starting with proper, actual training and restricting access to low code solution to people that have at least some technical literacy which often does not happen.

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

#75

Post by AtNightWeCode »

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.

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

#76

Post by jjkaczor »

pjmlp wrote: post #71
jlarocco wrote: post #36

Earlier quoted context omitted.

"Low Code" is a new (to me) buzzword, but Microsoft has targeted that niche for a long time. Specifically I'm thinking of the older Visual Basics (3-6) and the advanced scripting and database features in Office.

I have seen first hand on some lifescience consulting gigs how VB.NET takes away people from R, Python and similar tools. It is the Excel experts that have outgrown the macros and VBA capabilities, and get IT to install Visual Studio with VB.NET on their computers. They then double down on their VBA skills and somehow get to produce something in Windows Forms, or an Excel AddIn for the task at hand and then get going…

Neither VB, VBA, VBScript nor VB.NET are "low-code" or "no-code", they all were rather code heavy... Some VBA 'apps' relied heavily on their hosted application object-model (Excel, Word, Visio, etc) - but there was still quite a bit of code that the average corporate Excel-wizard was never truly comfortable with.

In the Microsoft space, historically the true "no-code" solutions were Access Web Databases (no VBA allowed - of course they axed that whole service in 365, as they could not monetize it as well as SQL Azure), or web-capable Excel workbooks that rely exclusively on PowerPivot/functions (no VBA allowed), or web-enabled InfoPath Forms (also... no VBA allowed).

In their modern universe their equivalents are; PowerApps, PowerAutomate/Flow, LogicApps and PowerBI - just as the article states.

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

#77

Post by thrower123 »

m12k wrote: post #37

I'm currently porting a slackbot to Teams. Even with the backend logic and architecture mostly re-usable, the Teams bot is already taking at least 3x as long to code, simply because their documentation is so obscure. It feels like detective work, correlating data from 4 different tangentially related sources (AzureAD, app authorization flows, Graph, BotFramework). I've never had so many tabs open at once in my life.…

Bot Framework is horrible. It's the most ridiculous IM platform I've built anything for, and I've covered a good bit of the spectrum.

They really need to expose a full-featured API for Teams, something at least as powerful as what you used to be able to do with the UCMA SDK for Lync/SfB.

I've given up on anything ever getting exposed through Graph API in a timely manner. It took two or three years before you could get online/busy/away presence information on a user without outrageous, unsupported hacks.

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

#78

Post by haswell »

syshum wrote: post #74
haswell wrote: post #33

Earlier quoted context omitted.

> will cost companies millions in Vendor Lockin, rewrites, and all of the other problems that come with non-developers "developing" What many folks miss here is that companies still willingly proceed despite these drawbacks because of the value that the end result provides. These tradeoffs are often less apparent when coming from a software development background or working for a company that builds software. But if…

I agree somewhat, the problem with "business outcome perspective" likely means very short term thinking, get it done now, deal with the rest later. The people that cause the mess are not likely the ones that have to clean up the mess, people like me are. I prefer to greenfield things but instead I spend the majority of my time untangling the bad choices people made years before coming at it from a "business outcome p…

I tend to agree with you in most situations, but I do think there are some counter examples.

The recent rollout of various COVID tracking apps for large companies come to mind. There was no way to predict the need, and low code tools were leveraged heavily to spin up quick solutions. e.g. I believe SalesForce products were used for some of the "Vaccine Finder" types of sites that spun up in my state.

That aside, as a general rule, if these are such important projects, the business should expand its development org and improve internal processes to better react to business needs.

But it seems like an almost universal problem (especially outside of tech) that this just does not happen. There is often very limited appetite to take on the risk of a big dev project without understanding its value. You could argue that building a business case is a better way to prove that value, but on the other hand, if you can build a business case by literally implementing a solution, and bring data to leadership that clearly says "this is worthy of investment, and here's a v1 already working to prove our point", this appeals to the risk averse management types since it proves the need.

I don't think this is a great mode of operation, but I think it helps explain why we see such investment and growth in these tools.

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

#79

Post by jwally »

ajcp wrote: post #45
ethbr0 wrote: post #42

Earlier quoted context omitted.

Well said. > The moat protecting the market share of the big RPA companies is created by the mature deployment systems that enable large enterprises to run hundreds or thousands of automated processes This is completely incorrect . Managing processes and bots is the absolute easiest thing they do, because it's entirely under their control and a solved problem. The actual moat is legacy compatibility -- how broad a te…

100% agree. The real value of these RPA solutions is their orchestration capabilities, but that's not how they sell it. They will start bleeding customers as those systems they're automating are replaced with those that provide more surfaces to interact with (like API). The real utility RPA solutions are supposed to provide to the enterprise is cost savings. These savings should then be put toward upgrading those leg…

Maybe I'm too cynical, but my experience with RPA via automation-anywhere is that the primary audience isn't IT or Engineering, but frustrated Line-of-Business middle management who are tired of waiting for IT to build them a solution and can't get budget-approval for a third-party to do it for them.

Couple that with woo like "self-healing", "insights", and "big data", etc along with dog whistles like "People will be scared you're automating them out of a job. You need to use discretion when implementing solutions".

I feel like the way RPA is sold to big corporations is analogous to how health-food stores sell muscle supplements to teenage boys.

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

#80

Post by thrower123 »

I know somebody that spent a few days setting up a bunch of these things to handle contact forms on landing pages and that kind of sloggy boring projects. They work fine when they work, but things wig out with them often enough, or they decide that they haven't been run in X days, and are going to be reclaimed, that it's become a hassle that keeps somebody busy about half the time. Job security, if you introduce these low-code solutions, I suppose...
Post reply on HN