6 ms·

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

by dnndev 5y ago

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. They earned a project with developers. Yes it will cost more to rewrite it but the old system is still making money while the new one rolls out. At this point a low code solution makes no sense for me as a dev - believe me I have tried them. Kudos to MS.

MattGaiser 5y ago
I think low code works for smaller more routine projects where hiring devs is just not all that feasible.
- asdfman123 5y ago
  A lot of people stuck in places like, say, the accounting department have the soul of a dev. They like technology and want to automate things. And often times when they do that, they actually improve their departments quite a bit with stuff like VBA and Access projects (as uncool as they may seem to some). It works because "real" programming environments have learning curves that are hard to tackle if you have a day job, and even if you do tackle them, IT is probably not going to give you direct database access. I had a friend like this, who was bored as shit as an accountant. I convinced him to migrate his career to software and now he's in a data science master's program.
  - Asymmetryk 5y ago
    if I may be so bold ( and presumptuous my suggestion is of any value) I wondered if your friend would like the risk and structured securities aspects of actuarial catastrophe risk markets. This pretty much has everything in it, from chaos theory to the statistics of the cadence of liabilities upon the different kinds of financial engineering structure that are used to distribute * the liability and fund the most difficult to reinsure policies in the capital markets. edit : * and package, according to a tremendous variety of fiscal requirements and risk appetites. And naturally covering the most extreme conditions liability payments is historically a fascinating insight into how we developed our world across and binding together such tenuous links.
    - asdfman123 5y ago
      Actually he's super into stock options and all that stuff. I think he majored in finance. I was the one who convinced him to do programming (although he's heading towards data science I guess now). Also we had a falling out since then, so shrugs.
syshum 5y ago
>>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. Or more likely they leave the company, it breaks and no one knows how it worked, how it was suppose to work, or anything about it so they need to call in someone either from Internal IT, or and outside consultant to figure out what broke, and how to fix it...
- brixon 5y ago
  No difference than Excel Macro apps today. When Excel Macro wiz kid leaves the department or the company and it either breaks or needs new features then it goes to IT and they don't work on Excel so they will push to rewrite it into a web app. The plus is that the use case and value for the program is already proven, so IT is not wasting time creating things people will not use.
- F_J_H 5y ago
  Yes this happens...sometimes. And, other times, (as reflected in comments ITT), there are many cases where a low-code solution built by a non-dev have brought huge benefit. (I've seen this myself - see below - MS Access apps that saved hours and hours of work, but which IT had not time to look at.) I've also seen the sentiment in your comment lead to an outright ban by IT dept. of all low-code tools, for no other reason than the "slippery slope fallacy" that "if we allow this, we could potentially have a big mess to sort out one day". And in doing so, summarily kill a ton of innovation and productivity. One anecdote I remember - a regulatory change created a major issue for a billing department. They went to IT to get their help to address it, and were told "sorry, no time to even talk to you right now. Come back in six months. Actually, make that 8 months." So, a tech. savvy person in the billing dept. built something in MS Access that solved the problem. They were thrilled. When IT heard about it, they tried to get the guy fired. Billing Dept. manager had to go to bat to make sure that didn't happen.
  - syshum 5y ago
    My counter, and anecdote, to this is the IT Dept recation is not so much a "slippery slope fallacy" but rather a reaction to past actual experiences it is ironic that you bring up Access because that is one the tools I despise the most, our helpdesk is routinely indated with requests from people that pass around Access Databases with custom data links either to Excel files, or ODBC connections that are not standard but rather customized by the "power user" that created the database, then they share the database and it generates all kind of errors that the non-power user can not fix so IT gets roped into spending our time fixing not only users system to establish the needed data links, but also moving things around and reconstructing the databases so it actually works in way that is shareable The IT Dept has also spent countless hours correcting Access Database connection issues, and schema issues when we move servers, upgrade platforms, or do anything on the prod system that end up breaking the Excel and Access "Low Code Applications" that consume data from these services because the end user lacks the technical ability to fix them often because they were created years ago by people that have left the company or retired.
asdfman123 5y ago
Yeah, this is pretty much the use case for low-code solutions like Access. Being a developer is an exception, rather than the rule, and there are a lot of smart BAs out there who know software could improve their lives. I feel like if AI gets really good, low-code is the future. In the future we won't eliminate software engineering but it will become increasingly less technical until software devs and BAs merge as one profession. But that's decades off if it comes at all.
stuaxo 5y ago
I'm sure a lot of projects would never make it to developers if somebody out in the field wasn't trying to solve a problem like this in the first place.
LeifCarrotson 5y ago
Yes, no-code solutions almost always become ugly, buggy, monstrosities, and there are technical limits that mean it needs wholesale replacement, but pragmatically I too have seen them getting jobs done. I'd also wager it will not cost more to rewrite it, especially if you deeply discount the non-developer resources that were used to create it (often salaried employees' time, and even then those individuals likely came out ahead compared to the tedium of doing it manually). Consider it a prototype. Also, the functional spec of "do exactly what the domain expert made this convoluted Excel spreadsheet do for the last 2 years, but with better validation of inputs" is often far more accurate than some daydreamed RFQ. The part that confuses me is why this makes sense as a separate enterprise product. Had the original author been interested in learning a new tool, they'd have probably been better off starting with Python. I recognize that non-developers are silently building their own tools, some of which will be a hit and later need replacement by developers, but are there really sales teams going around to big enterprises suggesting that they buy licenses for all their employees to be able to build their own tools using their particular low-code solution that will eventually be replaced? Seems like a difficult thing to sell IMO...
- nightski 5y ago
  Not everything is a large ugly, buggy monstrosity that needs to be rewritten into "real software". There are may business processes served quite well by excel which might be enhanced with a low code solution like this and could stay that way for over a decade.
  - Spooky23 5y ago
    Usually significant low code stuff is more reflective of organizational politics than anything else. Individual or small team productivity is one thing, the bigger low code monstrosities are usually a way for a vendor to weasel in and sell services under the IT peoples noses. The power automate bullshit cements whatever legacy junk it is feeding into and makes Azure the happy path for modernization.
- tolstoshev 5y ago
  On the flip side, there's plenty of ugly, buggy, code monstrosities that have to be rewritten or refactored. This just means the professional developer gets to start with a clean codebase with the UI & processes already laid out as an example. Almost like the no-code is a working prototype in place of a requirements doc.
jlarocco 5y ago
"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.
- pjmlp 5y ago
  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.
  - jjkaczor 5y ago
    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.
golergka 5y ago
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.
- dnndev 5y ago
  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.
  - JohnL4 5y ago
    THAT comment contributes nothing to the thread.
  - golergka 5y ago
    I apologize if my comment upset you or was offensive to you in any way. I only meant to notice that your comment paints a picture of all such projects being awful, and this may not be a faithful representation of reality. If you didn't mean to paint such a picture, I'm sorry for misunderstanding.
codingdave 5y ago
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.
- leejoramo 5y ago
  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.

by dnndev 5y ago

MattGaiser 5y ago

I think low code works for smaller more routine projects where hiring devs is just not all that feasible.

asdfman123 5y ago
A lot of people stuck in places like, say, the accounting department have the soul of a dev. They like technology and want to automate things. And often times when they do that, they actually improve their departments quite a bit with stuff like VBA and Access projects (as uncool as they may seem to some). It works because "real" programming environments have learning curves that are hard to tackle if you have a day job, and even if you do tackle them, IT is probably not going to give you direct database access. I had a friend like this, who was bored as shit as an accountant. I convinced him to migrate his career to software and now he's in a data science master's program.
- Asymmetryk 5y ago
  if I may be so bold ( and presumptuous my suggestion is of any value) I wondered if your friend would like the risk and structured securities aspects of actuarial catastrophe risk markets. This pretty much has everything in it, from chaos theory to the statistics of the cadence of liabilities upon the different kinds of financial engineering structure that are used to distribute * the liability and fund the most difficult to reinsure policies in the capital markets. edit : * and package, according to a tremendous variety of fiscal requirements and risk appetites. And naturally covering the most extreme conditions liability payments is historically a fascinating insight into how we developed our world across and binding together such tenuous links.
  - asdfman123 5y ago
    Actually he's super into stock options and all that stuff. I think he majored in finance. I was the one who convinced him to do programming (although he's heading towards data science I guess now). Also we had a falling out since then, so shrugs.

syshum 5y ago

>>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. Or more likely they leave the company, it breaks and no one knows how it worked, how it was suppose to work, or anything about it so they need to call in someone either from Internal IT, or and outside consultant to figure out what broke, and how to fix it...

brixon 5y ago
No difference than Excel Macro apps today. When Excel Macro wiz kid leaves the department or the company and it either breaks or needs new features then it goes to IT and they don't work on Excel so they will push to rewrite it into a web app. The plus is that the use case and value for the program is already proven, so IT is not wasting time creating things people will not use.
F_J_H 5y ago
Yes this happens...sometimes. And, other times, (as reflected in comments ITT), there are many cases where a low-code solution built by a non-dev have brought huge benefit. (I've seen this myself - see below - MS Access apps that saved hours and hours of work, but which IT had not time to look at.) I've also seen the sentiment in your comment lead to an outright ban by IT dept. of all low-code tools, for no other reason than the "slippery slope fallacy" that "if we allow this, we could potentially have a big mess to sort out one day". And in doing so, summarily kill a ton of innovation and productivity. One anecdote I remember - a regulatory change created a major issue for a billing department. They went to IT to get their help to address it, and were told "sorry, no time to even talk to you right now. Come back in six months. Actually, make that 8 months." So, a tech. savvy person in the billing dept. built something in MS Access that solved the problem. They were thrilled. When IT heard about it, they tried to get the guy fired. Billing Dept. manager had to go to bat to make sure that didn't happen.
- syshum 5y ago
  My counter, and anecdote, to this is the IT Dept recation is not so much a "slippery slope fallacy" but rather a reaction to past actual experiences it is ironic that you bring up Access because that is one the tools I despise the most, our helpdesk is routinely indated with requests from people that pass around Access Databases with custom data links either to Excel files, or ODBC connections that are not standard but rather customized by the "power user" that created the database, then they share the database and it generates all kind of errors that the non-power user can not fix so IT gets roped into spending our time fixing not only users system to establish the needed data links, but also moving things around and reconstructing the databases so it actually works in way that is shareable The IT Dept has also spent countless hours correcting Access Database connection issues, and schema issues when we move servers, upgrade platforms, or do anything on the prod system that end up breaking the Excel and Access "Low Code Applications" that consume data from these services because the end user lacks the technical ability to fix them often because they were created years ago by people that have left the company or retired.

asdfman123 5y ago

Yeah, this is pretty much the use case for low-code solutions like Access. Being a developer is an exception, rather than the rule, and there are a lot of smart BAs out there who know software could improve their lives. I feel like if AI gets really good, low-code is the future. In the future we won't eliminate software engineering but it will become increasingly less technical until software devs and BAs merge as one profession. But that's decades off if it comes at all.

stuaxo 5y ago

I'm sure a lot of projects would never make it to developers if somebody out in the field wasn't trying to solve a problem like this in the first place.

LeifCarrotson 5y ago

Yes, no-code solutions almost always become ugly, buggy, monstrosities, and there are technical limits that mean it needs wholesale replacement, but pragmatically I too have seen them getting jobs done. I'd also wager it will not cost more to rewrite it, especially if you deeply discount the non-developer resources that were used to create it (often salaried employees' time, and even then those individuals likely came out ahead compared to the tedium of doing it manually). Consider it a prototype. Also, the functional spec of "do exactly what the domain expert made this convoluted Excel spreadsheet do for the last 2 years, but with better validation of inputs" is often far more accurate than some daydreamed RFQ. The part that confuses me is why this makes sense as a separate enterprise product. Had the original author been interested in learning a new tool, they'd have probably been better off starting with Python. I recognize that non-developers are silently building their own tools, some of which will be a hit and later need replacement by developers, but are there really sales teams going around to big enterprises suggesting that they buy licenses for all their employees to be able to build their own tools using their particular low-code solution that will eventually be replaced? Seems like a difficult thing to sell IMO...

nightski 5y ago
Not everything is a large ugly, buggy monstrosity that needs to be rewritten into "real software". There are may business processes served quite well by excel which might be enhanced with a low code solution like this and could stay that way for over a decade.
- Spooky23 5y ago
  Usually significant low code stuff is more reflective of organizational politics than anything else. Individual or small team productivity is one thing, the bigger low code monstrosities are usually a way for a vendor to weasel in and sell services under the IT peoples noses. The power automate bullshit cements whatever legacy junk it is feeding into and makes Azure the happy path for modernization.
tolstoshev 5y ago
On the flip side, there's plenty of ugly, buggy, code monstrosities that have to be rewritten or refactored. This just means the professional developer gets to start with a clean codebase with the UI & processes already laid out as an example. Almost like the no-code is a working prototype in place of a requirements doc.

jlarocco 5y ago

"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.

pjmlp 5y ago
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.
- jjkaczor 5y ago
  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.

golergka 5y ago

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.

dnndev 5y ago
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.
- JohnL4 5y ago
  THAT comment contributes nothing to the thread.
- golergka 5y ago
  I apologize if my comment upset you or was offensive to you in any way. I only meant to notice that your comment paints a picture of all such projects being awful, and this may not be a faithful representation of reality. If you didn't mean to paint such a picture, I'm sorry for misunderstanding.

codingdave 5y ago

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.

leejoramo 5y ago
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.