Live data from Hacker News

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

infoq.com

51–60 of 198 posts

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

#51
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.…

I can see that. I think you're best bet is to throw that BotFramework out. I'm not sure why they keep it around, but they've all but replaced it with Power Virtual Agents.

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

#52
post #48

Earlier quoted context omitted.

> but I think MSFT also gets their own messaging wrong. Or, is it possible MSFT knows that when selling to "enterprise", it works a lot better to say you've got a better version of "thing they know", instead of a brand new thing that will replace "thing they know".

It very well could be. I think where MSFT gets mixed up is that they are obsessed with their products being able to solve *everyone's* use-case. Which means if they're talking to the business then it's a friendly "Low-Code" platform that any citizen developer can use. However, when they're talking to IT it's an amazing CI/CD tool for developing powerful enterprise applications! What's something that corporate IT is o…

MSFT is just doing so well at getting "enterprise" lock-in, that I'm reluctant to conclude they are getting anything at all "mixed up" in their messaging to decision-makers. At present they seem to be doing it exactly right for their business goals.

I have worked at and know of so many place that are "no, you can't spend money on that product, you have to use the equivalent from MSFT that is already included in our deal." Which is one reason it might be in MSFT's benefit to convince you that their thing is in the same class as some other thing you could spend money on, or may already be spending money on. And also, yeah, they are indeed convincing decision-makerse that they meet everyone's use-case and is whatever you want it to be, it's working....

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

#54
How much of the differentiation here is because Microsoft is innovating better versus simply their size and ability to use existing sales pipelines and bundling to push these types of features/products? This article even includes a Teams versus Slack graph in it - I can't help but feel sorry for smaller players who will see a gigantic incumbent unfairly eat their lunch without performing the hard work of innovation in the first place.

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

#55
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…

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.

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

#58
post #48

Earlier quoted context omitted.

It very well could be. I think where MSFT gets mixed up is that they are obsessed with their products being able to solve *everyone's* use-case. Which means if they're talking to the business then it's a friendly "Low-Code" platform that any citizen developer can use. However, when they're talking to IT it's an amazing CI/CD tool for developing powerful enterprise applications! What's something that corporate IT is o…

MSFT is just doing so well at getting "enterprise" lock-in, that I'm reluctant to conclude they are getting anything at all "mixed up" in their messaging to decision-makers. At present they seem to be doing it exactly right for their business goals. I have worked at and know of so many place that are "no, you can't spend money on that product, you have to use the equivalent from MSFT that is already included in our d…

I agree. I think that's also true of all the cloud players these days honestly.

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

#59
post #34

Microsoft has always had the best developer tools. This is an exciting step forward for low-code

Coming up in the time when MSFT was the "big evil" it's almost depressing to see myself now as an actual fan-boy.

The thing is, even when they were big evil, they had the best developer tooling by a mile. Visual Studio, MSDN, etc were novel and leagues ahead of other platform providers’ equivalents

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

#60
There has been a huge push for low-code over the last couple of years. The idea that anybody can setup a business flow is compelling and easily sold. But low code means a lot of config and these systems are nothing new and over time they will sooner or later become limiting. If you have everything in code any problem can be solved.

You also still need to solve the things like CI/CD, CM, dependencies, data modelling, correctness, resilience, security, compliance, integrations and so on.

Post reply on HN