This is implicitly written from the point of view of someone who is already skilled at programming. There’s a different point of view, that of the people who are bright and understand the problem domain very well, but are not skilled in any “production grade” programming languages. This group can benefit greatly from low code tools – think of Excel as a prominent example.
This group can benefit greatly from low code tools – think of Excel as a prominent example.
Yes and no.
The benefit of having “someone who is already skilled at programming”, in most organizations, is not that they can invent cutting-edge algorithms and data structures or whatever, it’s that they understand the scope of what’s possible and can bring the tools of programming to bear on the organization’s problems.
For example, a few jobs ago I worked at a place where an important internal process was being done via Excel. Specifically, via a gigantic Excel spreadsheet being used in lieu of a database, which certain people would open up (took a while on their laptops due to the size of the spreadsheet) and then have a stack of documents to review. Each one had certain codes on it, and they’d have to search the spreadsheet for the codes, one by one (which took a while due to the size of the spreadsheet) to look up rules for those codes, make a note of the rules, look up the next code, etc., and then finally check whether all the rules had been followed for that document’s codes. Then on to the next document. And they were spending multiple minutes sitting there waiting for Excel to chug away searching this giant spreadsheet.
But they also had some actual programmers on staff, who found out about this process and replaced it with a simple app that used a SQL database to store a copy of the codes and rules, and the people doing this could now just key in all the codes at once and get back the combined results in under a second. This was a vast improvement to both productivity and quality of life for the people involved in that process, but it involved the most boring banal tech imaginable: slurping a spreadsheet into a database and wrapping a little app around it to do the queries, something that popular libraries and frameworks solved decades ago. It was literally an afternoon’s work for a competent programmer.
Yet without the programmer they likely never would have gotten that, because the people who needed it would not have known to ask for that in the first place – they had no idea what was possible, what was easy or hard, etc.
It is my belief that anybody who thinks that Excel is a low-code tool has not met a sufficiently advanced workbook doing financial modeling, projections, or similar.
I have seen finite element analysis of all things done in an Excel workbook.
I call it “low-code” in order to emphasize that Excel does a lot of things automatically, not to disparage it as a tool without power. I have seen Sufficiently Advanced work in Excel; it’s clearly the work of wizards, just wizards who speak a foreign tongue.
Not to hound you, but when you say “does a lot of things automatically”, what are you thinking of? One could make the argument that my C compiler does a lot of things automatically when compared to hand-writing assembly, for example.
The big thing in Excel is that it gives you a reactive programming environment out of the box. You don’t need to write any logic to propagate changes to data through the system. It will resolve all dependencies for you and do incremental recomputation (and tell you when you have dependency cycles).
The defining feature for me of low code is the target audience.
Sufficiently advanced workbooks exist as long as your tool doesn’t have a sufficiently low capability ceiling. I’ve heard that in the low-code mobile app world that many of them support injecting more traditional code, eg. managed through a widget system, so I expect there are low-code apps making the most of the capability ceiling.
One of the essential skills of a software engineer is organization for purpose. I expect many people are familiar with Excel idioms which are poorly organized for future extensibility, robustness, isolation of issues, or durability under turnover. In some of these cases, Excel has the mechanisms by which a workbook could be organized, but isn’t from a lack of use. For example, columns and ranges can be given names and used by name in formulas, but instead, you might see Page!A2:D5. You could think of many ways to do data validation, express intent, be explicit, avoid manual synchronization, and so on. I think the absence of this has more to do with skill and context more than tooling.
Another job skill for software engineers is to refine business requirements. Business requirements as specified by the business are not specific enough to be a viable solution. The more experienced game developers that I know what work on one-off contracts identified that their most efficient workflow was to build a guess of what the client wanted, and throw out / rewrite everything that missed. I never saw a case where the initial ask matched the final result. When I write programs, the high level implementation strategy I have in mind (already a very detailed specification), isn’t fully specified until it’s fully implemented.
Despite the “debt” this creates, I think that opening up software to a general audience as Excel has is a productivity improvement that rivals high-level, platform portable programming languages. This is from the perspective of a programmer who no longer needs to be employed to write a computer program to summarize data (eg. compute max and mean of salaries). That program has already been written by the person who wanted to know the answer before even asking me, the hypothetical analyst programmer, so I don’t even need to know that the program existed.
I think this point is what the author sees as a problem, and I partially agree with you, some people need nothing more then Excel, which the article doesn’t distinguish from the messy use of excel.
Solving a problem in, say, Excel, as you mention, is fine if you have your own little problem. What happens in a bigger company is often the much-memed “Master calculator DO NOT EDIT (Copy 1).xls”. I think that’s what the author means of where low code is working around the process problem.
If you had a good solution, even low code, then why the extra meta info in the (made-up) file name?
I have yet to see a production spreadsheet “app” that wouldn’t benefit from an actual engineer with RDBMS experience giving it some TLC.
There might be some, somewhere.
I believe that instead of investing in low-code tools, it would be a lot better to give people access to actual IT knowledge.
Some employers pay for language courses. Why not teach some basic programming along with advanced spreadsheets as well as recap high school math?
Haida from Aggretsuko is a nice example of a knowledgeable power user who stepped out of cell math into the domain of macros, saving the whole department from a lot of tedious work. Shouldn’t this be encouraged?
I have yet to see a production spreadsheet “app” that wouldn’t benefit from an actual engineer with RDBMS experience giving it some TLC.
I agree, if you ignore economics. I’ve seen situations where a spreadsheet app has been replaced by a real RDBMS system and then that system hasn’t been able to adapt as quickly as user needs change and so the end result has been an authoritative pile of Excel that periodically gets a subset entered in the RDBMS. Properly understanding user needs and how those needs will change over the lifetime of a business-logic app and creating something flexible enough for that, maintainable, and correct is typically multiple engineer-years worth of work (plus opportunity cost from having the people that do the real work doing requirements analysis with the engineers). When that system is used by 10 people, it needs to give at least a 30-40% productivity improvement to be worthwhile doing and that’s rare. When the system is used by 1,000 people, the economics shift and it’s definitely worth doing properly.
The goal of low-code and no-code tools is to make it feasible to write something cheaply where even hiring one engineer to work on the problem would be prohibitively expensive. I see a lot of potential for LLM-based tooling in this space.
Power users? Definitely. As long as they do not have a direct line to the developer and/or are not able to modify them themselves. Rest of them are just going to use whatever you give them. I have seen people write records in literal books, in front of their computers, and then filter through them manually once per month, retyping 1/12 rows to Excel just to print them.
But in truth, I don’t believe low-code solves this either. There is going to be a gatekeeper who maintains it anyway.
I agree for the most part, but not with the estimates. I still believe that tools like Django with it’s admin interface may be a good match for many cases, providing integrity guarantees and rather easy migrations, while being affordable for most institutions.
IF you avoid scope explosion and the tendency to build “dumbed down” interfaces on top of it.
But, there definitely is a niche for power users who know how to actually build a good spreadsheet system that saves time. I believe that you’ve misunderstood me when I have written:
I have yet to see a production spreadsheet “app” that wouldn’t benefit from an actual engineer with RDBMS experience giving it some TLC.
I meant that literally a lot of those spreadsheet apps are very poorly designed. They don’t make use of primary keys between sheets, don’t highlight invalid entries and so on. I believe that we should have more people who understand these issues and can work out a reasonable designs. Then they might one day (with the help of CharGPT or whatever) be the ones building the business-specific mini systems. Or end up in management, actually asking the right questions about the character of processes they manage.
But since nowadays there isn’t much middle ground between “let’s contract out another business system for couple million” and “too expensive, let them do it by hand” in our culture… we jump to these “low-code” solutions because they offer autonomy. Which is kind of funny, because the expensive part is actually agreeing on the model and actions, not coding. So they inevitably scale about as well as the spreadsheet. And without the necessary skills they will end up about as bad.
And if not, then only be the virtue of being designed to be more didactic than spreadsheet. I believe.
I suspect that the people who can benefit from this kind of initiative are who could get around with ChatGPT pretty well.
The others (I’d say the majority) cannot even comprehend the advanced use of Excel.
OTOH, I have seen some pretty conservative bureaucrats liven up when they started to be involved in shaping their own tools, to the point of “I would love to learn to do it myself.”.
So there is a chance that it isn’t always about “the character”. It might be the circumstances.
And to be honest, it’s mostly the stupid bootlicking management who is responsible. “Yeah, we will pay for the course, but you have to sign here that you wouldn’t leave for another 2 years or you owe us” works wonders to stop people who want to learn.
Sure, every sufficiently complex spreadsheet would be better as a proper app. But if you needed to spend the money an staff a proper app costs to have created it in the first place it wouldn’t exist.
I think the article would have benefited from being called “Writing code isn’t the hard part” since that really seemed to be the main point. Once you have decomposed the problem and modeled solutions, writing the code is just a matter of translating that into whatever language you want (or need) to use. About two years ago someone here recommended How to Design Programs and I started using it as the textbook for my Fundamental Programming Concepts course (the only FP course our school has so far) and hands-down the biggest benefit has been the Function Design Recipe. I’ve started adapting it to my other classes, even the AP-level ones with good results. Obviously it is tailored to an FP model, but there are similar things you can do in OOP too. Anyway, it’s helped my students see that most of the work happens before you ever touch the keyboard. The way this article is titled and starts out makes it seem like the author is offended by “easy” languages or environments, and I don’t think that’s really the case. He just wants people to understand that the heavy lifting happens earlier in the process.
Yes, the function design recipe is really useful. I was teaching a student a year ago, and even though we were in Python, I went through the same structured process with her.
I would actually posit that this problem exists and is potentially more insidious in managers and senior leaders that do code but aren’t actively involved in the development of the problem solution at hand. In those cases they do know what the wave-toppy implementation could be but will underestimate the actual difficulty or unknown unknowns that crop up in the physical implementation. This can lead to misalignment and not understanding why things aren’t going as smoothly as the wave top version suggested.
I’m actually not sure where it originated? It means the high level details, or birds eye view of something.
In my comment above it would be like the senior engineer saying, “it just requires a few API calls, zipping the results, and them mapping to our domain value; how hard could it be?” While at a very high level that may be true, it glosses over any details of the actual problem being solved and how an implementation to do that would have to be built.
It’s difficult without an actual example, but I’ve seen this pattern often enough that I can’t be the only one to have noticed it.
that is the beginning and bane of all of my personal projects, ha. “How hard could it be?” - well, shit.
I’ve definitely applied that in professional contexts, though with more success than failure. But I definitely can see me getting it increasingly wrong. I’ve been recently (~8 months) promoted to a Staff title and don’t get to program as much as I used to. Managers get even less time, but still want to be part of the decision making process.
OTOH, I have witnessed a friend of mine tearing a government agency a new one couple of years back when he was still a member of Parliament.
The agency was supposed to implement an online solution to pay the highway fee. You enter the plate number, pay with credit card and for a given amount of time, the police has the plate.paid = true somewhere in a shared table and won’t bother you.
They have spent an inordinate amount of money on it. Something like 20 million USD for max 10 million users who buy at most one per year. And failed to deliver.
The friend has pointed out the fact, in the discussion surrounding it with people advocating for the agency, that they have “failed to implement an eshop where you don’t even have to deliver anything”. “A small software company would probably ask for less than 100k USD. I have personally worked on such shops. What are you even saying?”
So… Keep you skepticism. Don’t be too handwavy, but when it feels like something doesn’t add up, someone might very well be bullshitting you.
What I found Low-Code to be really good at is removing a barrier of entry for people who held a deep belief of “I can’t program”. Well, turns out they sometimes can, and they just feel more comfortable with a graphical representation of a program than a textual one.
As it also turns out, handing very junior developers-who-believe-they-arent-developers something that can aptly be described as the graphical representation of Visual Basic is often not the best of ideas. That’s why those products are nourishing a growing ecosystem of consultancies to pick up the eventually resulting mess.
Professional problem solvers is accurate. My org tried to use some product that wrapped around google sheets and it used web hooks to integrate with our primary application. It just became a constraint drain on an engineer to debug and diagnose an issue. Later the same engineer made an in house micro service to handle it and we’ve had few issues since. The editor of the no code / low code product could not solve the problem and could not diagnose the problems they introduced. At the same time, that editor could do things the engineer could not: directing customer support.
The pipe dream behind low code is to provide independence to everyone while engineering resources are constrained. Buyers of these services find out later that there is no shortcut to understanding the problem to be solved.
The problem is also that we humans play loose and wing everything.
Many modern languages (Python and Haskell being exceptions here) don’t even integers. You probably frown, but what we call 32-bit integers are not integers, they are 32 bits. We can interpret them as a representation for integers modulo 2^32. We can pretend they are integers, but then it’s essential to know whether an operation has overflown or not. Most languages don’t even have that. So we fail even at implementing integer arithmetic which is the most basic building block.
Stuff like this (leaky abstractions in interfaces) happens at every level, not the language level.
Lisp used integers that were either 31-bit integers in a word with a tag bit or pointer to a big integer object prior to the Scheme / Common Lisp split. Alan Kay copied it for Smalltalk a couple of years before Scheme was created, by reading Lisp implementation papers from the ’60s.
Ah, but low code is not software development it is solving business problems, cleansing data, integrating disconnected data sources, automating weird one-off requirements.
You can do all of the above with commercial and open source low code platforms and they are pretty great for getting a lot of these things done by people who are not software engineers.
TBH were I currently work I would greatly benefit from an officially sanctioned tool that can do some of the things I am currently doing with “proper software engineering”. A tool that is already blessed by security and has all the necessary access is 10 times more productive than the endless reviews and whatnots I am currently dealing with.
Full disclosure: I have worked for companies making low-code platforms, so I may be biased, but there are def. use cases for these.
One thing to say in defense of low/no code: most non-programmers can’t upcase a string without retyping it. Nocode doesn’t need to do software development to make people’s computer lives better.
This is implicitly written from the point of view of someone who is already skilled at programming. There’s a different point of view, that of the people who are bright and understand the problem domain very well, but are not skilled in any “production grade” programming languages. This group can benefit greatly from low code tools – think of Excel as a prominent example.
Yes and no.
The benefit of having “someone who is already skilled at programming”, in most organizations, is not that they can invent cutting-edge algorithms and data structures or whatever, it’s that they understand the scope of what’s possible and can bring the tools of programming to bear on the organization’s problems.
For example, a few jobs ago I worked at a place where an important internal process was being done via Excel. Specifically, via a gigantic Excel spreadsheet being used in lieu of a database, which certain people would open up (took a while on their laptops due to the size of the spreadsheet) and then have a stack of documents to review. Each one had certain codes on it, and they’d have to search the spreadsheet for the codes, one by one (which took a while due to the size of the spreadsheet) to look up rules for those codes, make a note of the rules, look up the next code, etc., and then finally check whether all the rules had been followed for that document’s codes. Then on to the next document. And they were spending multiple minutes sitting there waiting for Excel to chug away searching this giant spreadsheet.
But they also had some actual programmers on staff, who found out about this process and replaced it with a simple app that used a SQL database to store a copy of the codes and rules, and the people doing this could now just key in all the codes at once and get back the combined results in under a second. This was a vast improvement to both productivity and quality of life for the people involved in that process, but it involved the most boring banal tech imaginable: slurping a spreadsheet into a database and wrapping a little app around it to do the queries, something that popular libraries and frameworks solved decades ago. It was literally an afternoon’s work for a competent programmer.
Yet without the programmer they likely never would have gotten that, because the people who needed it would not have known to ask for that in the first place – they had no idea what was possible, what was easy or hard, etc.
It is my belief that anybody who thinks that Excel is a low-code tool has not met a sufficiently advanced workbook doing financial modeling, projections, or similar.
I have seen finite element analysis of all things done in an Excel workbook.
I call it “low-code” in order to emphasize that Excel does a lot of things automatically, not to disparage it as a tool without power. I have seen Sufficiently Advanced work in Excel; it’s clearly the work of wizards, just wizards who speak a foreign tongue.
Not to hound you, but when you say “does a lot of things automatically”, what are you thinking of? One could make the argument that my C compiler does a lot of things automatically when compared to hand-writing assembly, for example.
The big thing in Excel is that it gives you a reactive programming environment out of the box. You don’t need to write any logic to propagate changes to data through the system. It will resolve all dependencies for you and do incremental recomputation (and tell you when you have dependency cycles).
The defining feature for me of low code is the target audience.
Sufficiently advanced workbooks exist as long as your tool doesn’t have a sufficiently low capability ceiling. I’ve heard that in the low-code mobile app world that many of them support injecting more traditional code, eg. managed through a widget system, so I expect there are low-code apps making the most of the capability ceiling.
One of the essential skills of a software engineer is organization for purpose. I expect many people are familiar with Excel idioms which are poorly organized for future extensibility, robustness, isolation of issues, or durability under turnover. In some of these cases, Excel has the mechanisms by which a workbook could be organized, but isn’t from a lack of use. For example, columns and ranges can be given names and used by name in formulas, but instead, you might see
Page!A2:D5. You could think of many ways to do data validation, express intent, be explicit, avoid manual synchronization, and so on. I think the absence of this has more to do with skill and context more than tooling.Another job skill for software engineers is to refine business requirements. Business requirements as specified by the business are not specific enough to be a viable solution. The more experienced game developers that I know what work on one-off contracts identified that their most efficient workflow was to build a guess of what the client wanted, and throw out / rewrite everything that missed. I never saw a case where the initial ask matched the final result. When I write programs, the high level implementation strategy I have in mind (already a very detailed specification), isn’t fully specified until it’s fully implemented.
Despite the “debt” this creates, I think that opening up software to a general audience as Excel has is a productivity improvement that rivals high-level, platform portable programming languages. This is from the perspective of a programmer who no longer needs to be employed to write a computer program to summarize data (eg. compute max and mean of salaries). That program has already been written by the person who wanted to know the answer before even asking me, the hypothetical analyst programmer, so I don’t even need to know that the program existed.
I think this point is what the author sees as a problem, and I partially agree with you, some people need nothing more then Excel, which the article doesn’t distinguish from the messy use of excel.
Solving a problem in, say, Excel, as you mention, is fine if you have your own little problem. What happens in a bigger company is often the much-memed “Master calculator DO NOT EDIT (Copy 1).xls”. I think that’s what the author means of where low code is working around the process problem.
If you had a good solution, even low code, then why the extra meta info in the (made-up) file name?
I have yet to see a production spreadsheet “app” that wouldn’t benefit from an actual engineer with RDBMS experience giving it some TLC.
There might be some, somewhere.
I believe that instead of investing in low-code tools, it would be a lot better to give people access to actual IT knowledge.
Some employers pay for language courses. Why not teach some basic programming along with advanced spreadsheets as well as recap high school math?
Haida from Aggretsuko is a nice example of a knowledgeable power user who stepped out of cell math into the domain of macros, saving the whole department from a lot of tedious work. Shouldn’t this be encouraged?
I agree, if you ignore economics. I’ve seen situations where a spreadsheet app has been replaced by a real RDBMS system and then that system hasn’t been able to adapt as quickly as user needs change and so the end result has been an authoritative pile of Excel that periodically gets a subset entered in the RDBMS. Properly understanding user needs and how those needs will change over the lifetime of a business-logic app and creating something flexible enough for that, maintainable, and correct is typically multiple engineer-years worth of work (plus opportunity cost from having the people that do the real work doing requirements analysis with the engineers). When that system is used by 10 people, it needs to give at least a 30-40% productivity improvement to be worthwhile doing and that’s rare. When the system is used by 1,000 people, the economics shift and it’s definitely worth doing properly.
The goal of low-code and no-code tools is to make it feasible to write something cheaply where even hiring one engineer to work on the problem would be prohibitively expensive. I see a lot of potential for LLM-based tooling in this space.
Users will treat crappy, inflexible applications as damage and use Excel to route around them.
Power users? Definitely. As long as they do not have a direct line to the developer and/or are not able to modify them themselves. Rest of them are just going to use whatever you give them. I have seen people write records in literal books, in front of their computers, and then filter through them manually once per month, retyping 1/12 rows to Excel just to print them.
But in truth, I don’t believe low-code solves this either. There is going to be a gatekeeper who maintains it anyway.
I agree for the most part, but not with the estimates. I still believe that tools like Django with it’s admin interface may be a good match for many cases, providing integrity guarantees and rather easy migrations, while being affordable for most institutions.
IF you avoid scope explosion and the tendency to build “dumbed down” interfaces on top of it.
But, there definitely is a niche for power users who know how to actually build a good spreadsheet system that saves time. I believe that you’ve misunderstood me when I have written:
I meant that literally a lot of those spreadsheet apps are very poorly designed. They don’t make use of primary keys between sheets, don’t highlight invalid entries and so on. I believe that we should have more people who understand these issues and can work out a reasonable designs. Then they might one day (with the help of CharGPT or whatever) be the ones building the business-specific mini systems. Or end up in management, actually asking the right questions about the character of processes they manage.
But since nowadays there isn’t much middle ground between “let’s contract out another business system for couple million” and “too expensive, let them do it by hand” in our culture… we jump to these “low-code” solutions because they offer autonomy. Which is kind of funny, because the expensive part is actually agreeing on the model and actions, not coding. So they inevitably scale about as well as the spreadsheet. And without the necessary skills they will end up about as bad.
And if not, then only be the virtue of being designed to be more didactic than spreadsheet. I believe.
I suspect that the people who can benefit from this kind of initiative are who could get around with ChatGPT pretty well. The others (I’d say the majority) cannot even comprehend the advanced use of Excel.
Hahaha. You may be right. Inquisitive types.
OTOH, I have seen some pretty conservative bureaucrats liven up when they started to be involved in shaping their own tools, to the point of “I would love to learn to do it myself.”.
So there is a chance that it isn’t always about “the character”. It might be the circumstances.
And to be honest, it’s mostly the stupid bootlicking management who is responsible. “Yeah, we will pay for the course, but you have to sign here that you wouldn’t leave for another 2 years or you owe us” works wonders to stop people who want to learn.
Sure, every sufficiently complex spreadsheet would be better as a proper app. But if you needed to spend the money an staff a proper app costs to have created it in the first place it wouldn’t exist.
I think the article would have benefited from being called “Writing code isn’t the hard part” since that really seemed to be the main point. Once you have decomposed the problem and modeled solutions, writing the code is just a matter of translating that into whatever language you want (or need) to use. About two years ago someone here recommended How to Design Programs and I started using it as the textbook for my Fundamental Programming Concepts course (the only FP course our school has so far) and hands-down the biggest benefit has been the Function Design Recipe. I’ve started adapting it to my other classes, even the AP-level ones with good results. Obviously it is tailored to an FP model, but there are similar things you can do in OOP too. Anyway, it’s helped my students see that most of the work happens before you ever touch the keyboard. The way this article is titled and starts out makes it seem like the author is offended by “easy” languages or environments, and I don’t think that’s really the case. He just wants people to understand that the heavy lifting happens earlier in the process.
Yes, the function design recipe is really useful. I was teaching a student a year ago, and even though we were in Python, I went through the same structured process with her.
I would actually posit that this problem exists and is potentially more insidious in managers and senior leaders that do code but aren’t actively involved in the development of the problem solution at hand. In those cases they do know what the wave-toppy implementation could be but will underestimate the actual difficulty or unknown unknowns that crop up in the physical implementation. This can lead to misalignment and not understanding why things aren’t going as smoothly as the wave top version suggested.
Aside: Wave top? I don’t remember seeing the expression before, what does it mean exactly? Where does it originate? If you don’t mind me asking.
I’m actually not sure where it originated? It means the high level details, or birds eye view of something.
In my comment above it would be like the senior engineer saying, “it just requires a few API calls, zipping the results, and them mapping to our domain value; how hard could it be?” While at a very high level that may be true, it glosses over any details of the actual problem being solved and how an implementation to do that would have to be built.
It’s difficult without an actual example, but I’ve seen this pattern often enough that I can’t be the only one to have noticed it.
that is the beginning and bane of all of my personal projects, ha. “How hard could it be?” - well, shit.
I’ve definitely applied that in professional contexts, though with more success than failure. But I definitely can see me getting it increasingly wrong. I’ve been recently (~8 months) promoted to a Staff title and don’t get to program as much as I used to. Managers get even less time, but still want to be part of the decision making process.
OTOH, I have witnessed a friend of mine tearing a government agency a new one couple of years back when he was still a member of Parliament.
The agency was supposed to implement an online solution to pay the highway fee. You enter the plate number, pay with credit card and for a given amount of time, the police has the
plate.paid = truesomewhere in a shared table and won’t bother you.They have spent an inordinate amount of money on it. Something like 20 million USD for max 10 million users who buy at most one per year. And failed to deliver.
The friend has pointed out the fact, in the discussion surrounding it with people advocating for the agency, that they have “failed to implement an eshop where you don’t even have to deliver anything”. “A small software company would probably ask for less than 100k USD. I have personally worked on such shops. What are you even saying?”
So… Keep you skepticism. Don’t be too handwavy, but when it feels like something doesn’t add up, someone might very well be bullshitting you.
What I found Low-Code to be really good at is removing a barrier of entry for people who held a deep belief of “I can’t program”. Well, turns out they sometimes can, and they just feel more comfortable with a graphical representation of a program than a textual one.
As it also turns out, handing very junior developers-who-believe-they-arent-developers something that can aptly be described as the graphical representation of Visual Basic is often not the best of ideas. That’s why those products are nourishing a growing ecosystem of consultancies to pick up the eventually resulting mess.
Professional problem solvers is accurate. My org tried to use some product that wrapped around google sheets and it used web hooks to integrate with our primary application. It just became a constraint drain on an engineer to debug and diagnose an issue. Later the same engineer made an in house micro service to handle it and we’ve had few issues since. The editor of the no code / low code product could not solve the problem and could not diagnose the problems they introduced. At the same time, that editor could do things the engineer could not: directing customer support.
The pipe dream behind low code is to provide independence to everyone while engineering resources are constrained. Buyers of these services find out later that there is no shortcut to understanding the problem to be solved.
The problem is also that we humans play loose and wing everything.
Many modern languages (Python and Haskell being exceptions here) don’t even integers. You probably frown, but what we call 32-bit integers are not integers, they are 32 bits. We can interpret them as a representation for integers modulo 2^32. We can pretend they are integers, but then it’s essential to know whether an operation has overflown or not. Most languages don’t even have that. So we fail even at implementing integer arithmetic which is the most basic building block.
Stuff like this (leaky abstractions in interfaces) happens at every level, not the language level.
Scheme was first, I believe.
But yeah, I can see how that can bite some inexperienced users.
Lisp used integers that were either 31-bit integers in a word with a tag bit or pointer to a big integer object prior to the Scheme / Common Lisp split. Alan Kay copied it for Smalltalk a couple of years before Scheme was created, by reading Lisp implementation papers from the ’60s.
I did not know about that. But I should have guessed. :-)
Ah, but low code is not software development it is solving business problems, cleansing data, integrating disconnected data sources, automating weird one-off requirements.
You can do all of the above with commercial and open source low code platforms and they are pretty great for getting a lot of these things done by people who are not software engineers.
TBH were I currently work I would greatly benefit from an officially sanctioned tool that can do some of the things I am currently doing with “proper software engineering”. A tool that is already blessed by security and has all the necessary access is 10 times more productive than the endless reviews and whatnots I am currently dealing with.
Full disclosure: I have worked for companies making low-code platforms, so I may be biased, but there are def. use cases for these.
One thing to say in defense of low/no code: most non-programmers can’t upcase a string without retyping it. Nocode doesn’t need to do software development to make people’s computer lives better.
I wrote what started as a reply to this, which then went sideways into me complaining about the current state of no-code.