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...
I don't use Teams because I like it, I use it because I have to at my company...
Microsoft's low-code strategy paints a target on UIPath and other RPA companies
91–100 of 198 posts
Re: Microsoft's low-code strategy paints a target on UIPath and other RPA companies
#92This 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…
I've been working in and supporting low-code environments off and on since the 90s (Lotus Notes -> Sharepoint -> Salesforce, if it matters) I've been the guy who does those re-writes when needed. I can confirm that the biggest and worst of them need re-writes, but most just need a little cleanup. Most are like you said, a non-programmer does something unwise. I spent much of my time giving people a "Dev 101" course to help them do it better, and they'd build heaps of apps that never needed re-writes.
Even when they did need taken over by IT because they scaled to a level of being business-critical, they rarely needed a full re-write, they most often just needed enhanced. Adding in validation, data integrity, backups, UX, testing, and simply streamlining the app with features that needed "real" code. And once a decade we'd re-platform them all as the underlying platforms become outdated and were eclipsed by something new.
It was amazing how well the non-programmers could do if given a weekly opportunity to just come in and show their work, ask questions, and get advice. Some of the people I coached even went on to learn how to code and have become successful software engineers in their own right.
If you ever end up supporting such environments again, I'd recommend considering yourself a mentor to new developers more so than someone who is going to clean up someone else's mess. People might surprise you with how much they are capable of.
Re: Microsoft's low-code strategy paints a target on UIPath and other RPA companies
#93Earlier quoted context omitted.
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…
You're not cynical, that is their strategy. It's why most IT organizations label RPA as "anti-pattern" and want nothing to do with it. It's sold in a way that explicitly calls into question ITs own utility, if not out-right calls it the problem! It's certainly not helpful. The only successful ROM (robotic operating model) implementations I have seen are ones that have the full-throated support and participation of IT…
The most beneficial model I've come up with was a cooperative one, where RPA is the wireframe / prototype of business automation requests to IT.
IT promise to business: "You can use RPA if we tell you we can't build a thing in time."
Business promise to IT: "We'll turn off RPA at such time as you deliver us a working solution."
And then be very particular that business needs to have documentation of their RPA in order to implement in production (business process / ask, notsomuch technical).
This accomplishes a few positive things: (1) takes {insert dumb / hard / bad ROI business request off IT's priority plate}, (2) forces business to think about what they actually want, (3) forces business to document what they actually want, (4) provides business the flexibility to change their automation, when the realize they don't want what they thought they wanted, & (5) burns not-developer time learning all the intricacies and quirks of {legacy software / website / data}.
In the end, when IT comes back around knocking, their business counterparts actually have gasp documentation. And furthermore, documentation that's actually been battle tested and seen prod systems & data.
(It's an admittance that most IT projects fail not for lack of technical feasibility, but for incomplete or shifting specs)
Re: Microsoft's low-code strategy paints a target on UIPath and other RPA companies
#94We 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.
Re: Microsoft's low-code strategy paints a target on UIPath and other RPA companies
#95This 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…
I've been working in and supporting low-code environments off and on since the 90s (Lotus Notes -> Sharepoint -> Salesforce, if it matters) I've been the guy who does those re-writes when needed. I can confirm that the biggest and worst of them need re-writes, but most just need a little cleanup. Most are like you said, a non-programmer does something unwise. I spent much of my time giving people a "Dev 101" course t…
100% agree with you.
I really enjoy supporting people who have already built their own tool, but need a programmer to take it to another level. Such projects tend to be well scoped, and the project owners are heavily invested in and understand their actual needs.
In 20+ years of professional programming, projects that started with the end user solving their own problems have nearly a 100% success rate.
Re: Microsoft's low-code strategy paints a target on UIPath and other RPA companies
#96Re: Microsoft's low-code strategy paints a target on UIPath and other RPA companies
#97I bet Microsoft's "Low Code" turns out to be "Slow Code".
Since the competition is Electron and JS, the bar is somewhere in the stratosphere.
Re: Microsoft's low-code strategy paints a target on UIPath and other RPA companies
#98Excel spreadsheets, and now low-code platforms, are how non-coders write functional specifications.
Re: Microsoft's low-code strategy paints a target on UIPath and other RPA companies
#99Earlier quoted context omitted.
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 work in an enterprise and use flow and other Power platform stuff. The sense I get is that management look at the headline features and see it as essentially safe. But Microsoft have included some features that will be exploited in unexpected ways that create a maintenance and security problem. A good example is that Flow/Power Automate can be triggered using an API end point. That can then be configured to provide…
Ah yes, the one spread sheet that everyone uses but no one knows how it works! I've seen that so many times.
Re: Microsoft's low-code strategy paints a target on UIPath and other RPA companies
#100Earlier quoted context omitted.
You're not cynical, that is their strategy. It's why most IT organizations label RPA as "anti-pattern" and want nothing to do with it. It's sold in a way that explicitly calls into question ITs own utility, if not out-right calls it the problem! It's certainly not helpful. The only successful ROM (robotic operating model) implementations I have seen are ones that have the full-throated support and participation of IT…
The most beneficial model I've come up with was a cooperative one, where RPA is the wireframe / prototype of business automation requests to IT. IT promise to business: "You can use RPA if we tell you we can't build a thing in time." Business promise to IT: "We'll turn off RPA at such time as you deliver us a working solution." And then be very particular that business needs to have documentation of their RPA in orde…
>IT promise to business: "You can use RPA if we tell you we can't build a thing in time."
>
>Business promise to IT: "We'll turn off RPA at such time as you deliver us a working solution."
This is the _whole_ life-cycle of a correct RPA implementation. The only successful RPA automation is the one that gets turned off because it has been solved for in the enterprise application level.