The non-tech F500 I worked at several years ago is doing everything they can to abandon .NET/Java in favor of low-code tools. Their engineers are jumping ship and they're having a hard time finding replacements.
>in favor of low-code tools. Their engineers are jumping ship and they're having a hard time finding replacements.
I have a friend who works for a major low-code software company. They're doing quite well financially because of all the excitement around low-code. The product is good if you stay within the boundaries of what it can do. Some managers people think they can replace their enterprise Tableau/Spotfire/PowerBI license with low-code and they get bitten very badly.
Finding engineers for a low-code environment is a challenge. You need to understand software development well enough that you can build something because loops, conditional statements, all of those concepts are there. You also need to find somebody who is willing to possibly lock their career into a single tool and forgo the benefits of knowing a general purpose language like C#, Python, etc.
Some companies have success with finding technically minded business people or IT folks who don't enjoy coding and training them. They can thrive and build some nice apps. Lots of folks can't make the leap and fail. Software Engineers are probably the worst bunch to try an convince because the opportunity cost is too high.
My nonprofit works with a very talented Microsoft consultancy to help our transition from on-prem servers to Microsoft 365 cloud. My main contact there (Director of Biz Operations) says they have transitioned most of their custom development from .NET to Power Apps/Power Automate. It's not the only toolset they use, but he says it's the right tool for many small-medium biz CRUD needs.
This is the direction my current employer is headed. I was sent on a week long course to evaluate the viability of PowerApps. While there is certainly some cool stuff in there, it just doesn't feel like we should be moving all our development there wholesale. There is certainly a time and place, or at least that is how it seems to me.
Business / money making / crucial systems? No. Some random HR survey application? Maybe. Sadly Microsoft seems to have convinced a number of folks in our organization that this tool set is appropriate for all our development.
Interesting, there was some low code at the last F500 I worked with, but mostly for very small tolls not requiring much of any business logic.
Majority of the services were older .NET framework projects with some other stuff scattered around. They had a sizable mainframe team, but we’re trying to migrate away from that platform.
apohn|3 years ago
I have a friend who works for a major low-code software company. They're doing quite well financially because of all the excitement around low-code. The product is good if you stay within the boundaries of what it can do. Some managers people think they can replace their enterprise Tableau/Spotfire/PowerBI license with low-code and they get bitten very badly.
Finding engineers for a low-code environment is a challenge. You need to understand software development well enough that you can build something because loops, conditional statements, all of those concepts are there. You also need to find somebody who is willing to possibly lock their career into a single tool and forgo the benefits of knowing a general purpose language like C#, Python, etc.
Some companies have success with finding technically minded business people or IT folks who don't enjoy coding and training them. They can thrive and build some nice apps. Lots of folks can't make the leap and fail. Software Engineers are probably the worst bunch to try an convince because the opportunity cost is too high.
Optimal_Persona|3 years ago
laughingpine|3 years ago
Business / money making / crucial systems? No. Some random HR survey application? Maybe. Sadly Microsoft seems to have convinced a number of folks in our organization that this tool set is appropriate for all our development.
the_only_law|3 years ago
the_only_law|3 years ago
Majority of the services were older .NET framework projects with some other stuff scattered around. They had a sizable mainframe team, but we’re trying to migrate away from that platform.