Live data from Hacker News

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

infoq.com

31–40 of 198 posts

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

#31
post #3

Who has actually seen a success story with this sort of thing? We arrived at "low-code", but by way of actually solving our problem domain through many hellish iterations and figuring out what all of the various points of configuration should be . As far as I am aware, this is not something that Microsoft or any other vendor can determine for your business ahead of time. I am sure that there are a lot of types of sma…

"Who has actually seen a success story with this sort of thing?"

Citizen development stuff is usually more successful than an IT department knows. They think it's failing because every time they hear about it, it's because of some mess. The thing is, they don't hear about all the stuff that works fine. There's typically a ton of MS Access, Quickbase, Excel, Google Sheets, Salesforce, etc, "apps" written and run by non-tech folks that the IT department never knows about.

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

#32

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

Using SQL to get reports and analyse existing data, or to actually create schemas, change data, maintain transactions over related changes and so on?

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

#33
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 you're in a different type of org - say financial services - these solutions are often the difference between launching a new product/capability, or putting structure around a paper process...or accomplishing absolutely nothing because development is currently tied up for the next two years.

Not all companies have IT/Dev orgs that are capable of meeting the demands of the business. Some orgs are transforming their businesses (the "digital transformation" buzzword), and don't have a dev team at all. At best, they have some centralized IT department that is capable of rolling out point solutions.

You might be right that these solutions are inherently inferior from a technical perspective, but if you look at this from a business outcome perspective, those tradeoffs are often worthwhile.

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

#35

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

We started leveraging SQL very heavily in our application so that business people can customize app behavior without bothering developers. We are getting close to 100% config-only coverage using SQL.

We tried rolling our own scripting language and other ideas, but we decided that we weren't ever going to catch up with the level of testing & validation that SQLite has achieved with any amount of in-house resources.

Once we embraced SQLite, we found an entire universe of capability. Here is one of the comments I made just yesterday about this kind of thing:

  https://news.ycombinator.com/item?id=27362708

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

#36
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.

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

#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. At one point, I gave up on their documentation, and just traffic-sniffed the library used in one of their example apps in another language, to figure which endpoint to call and which json format to send it. The jump from Slack to Teams feels like the difference between Rails and (Java) Spring - the former makes web-apps, the latter is a framework and dependency injection container, which can be used to make various apps and services, among them web-apps.

Long story short, MS is a master at making you appreciate the difference between "technically possible to achieve" and "easy and realistic to achieve". If my experience with them is any indication, MS still has a looong way to go before they can make their ecosystem of services accessible to "normal" people.

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

#40
post #26

Earlier quoted context omitted.

Do you consider Excel a low-code solution?

That depends on how you use excel. Lots of formulas, et. al. would probably become easier to manage as part of a proper codebase at some point.

On the flip side, some of those spreadsheets that reach the "would be easier to manage with a proper codebase" status never would have gotten off the ground had they started as a development project.
Post reply on HN