4 ms·

As someone who got their start in tech with a low-code environment (ServiceNow reporting) I have found the true value of low code is the ability for business/op

As someone who got their start in tech with a low-code environment (ServiceNow reporting) I have found the true value of low code is the ability for business/ops teams to create tools that serve their needs without waiting on a team of "real" developers to make time for them. One of the biggest benefits is the sense of excitement this creates for these users as they are able to add the logic of programming into a process that was formerly a manual one. When they do reach their "edge" around low-code, they can then engage development teams with better knowledge about the system and a clearer vision for what they need. As other comments have said, low-code will always have trouble solving special cases due to their very nature of being simple and interchangeable. However, empowering others to solve these low hanging fruit problems liberates the develops from a backlog full of basic functionality and allows them to focus on the big problems that will require more robust tooling and design.

alexpotato 4y ago
I 100% agree on the savings of real developer time when end users can self service. At the same time, I've also seen users do incredibly crazy things because either they didn't know any better or just didn't bother to "read the code". Good example of this is people just keep creating Statuses in JIRA until you end up with "Which of these 264 'Completed' statuses is the one I want?". It's similar to the Ops person "Hey, I wrote a Perl script that does what I want. Yay!" that turns out to be a spaghetti ball of copy/pasta. This is maybe less of a point about programming and more about governance. Either way, you will still need specialized people who make sure that everything is being done in some kind of guardrails.
- alphager 4y ago
  > At the same time, I've also seen users do incredibly crazy things because either they didn't know any better or just didn't bother to "read the code". Good example of this is people just keep creating Statuses in JIRA until you end up with "Which of these 264 'Completed' statuses is the one I want?". Why is this a problem? Programs are a means to an end. The 264 Jira statuses are messy and could be done away with, but would a clean solution actually change anything for the better? In a significant, "it was worth spending the money on a real developer" way?
  - ElectricalUnion 4y ago
    > Why is this a problem? Programs are a means to an end. The 264 Jira statuses are messy and could be done away with, but would a clean solution actually change anything for the better? In a significant, "it was worth spending the money on a real developer" way? "Let's not waste money on a programmer so instead everyone in the company wastes millions of man-hours every month slowly filling things the wrong way!" There is a lesson here for ambitious system architects: the most dangerous enemy of a better solution is an existing codebase that is just good enough. - The Art of Unix Programming
lostboomerang 4y ago
> As someone who got their start in tech with a low-code environment (ServiceNow reporting) I have found the true value of low code is the ability for business/ops teams to create tools that serve their needs without waiting on a team of "real" developers to make time for them. This is because a lot of so-called "real developers" nowadays think their job is to keep up with the latest fads and finding ways of chopping the business needs in a way so they fit better to the popular framework of the day. Business quickly grow tired of hearing "that's not possible" when what the developer actually means "what you want to do is against the architecture of the framework I've decided we must use". If the business insist, the developer spends a lot of time fighting the framework. Now, from a job market perspective, it is entirely understandable that the developer prefers to do RDD - resume driven development. But it also makes it fully understandable that the business people wants to find ways of solving their needs, that do not include waiting on the "real developers". Hence the Excel and Access monstrosities present in every org.
nonrandomstring 4y ago
> the true value of low code is the ability for business/ ops teams to create tools that serve their needs without waiting on a team of "real" developers to make time for them. I agree with this. There is a hidden market that exists between "Developers" and "End Users". With Pure Data, I found this in the games and interactive audio industry where much of the procedural sound we made was done by "artists" essentially. Rapid prototyping using visual languages gave "good enough" code that could be exported to C/C++ later for embedding. Again I saw that with LabView in industrial modelling, where engineers who are not at all "expert" coders could work within their domain of expertise and spit out code (also through tools like Matlab/Octave and NetLogo) as basically a very advanced (demonstrably working) "requirements spec" to any developer who wanted to take it further. The win comes when you realise the lifetime of many rapid prototypes is good enough, and real developers are expensive enough, that the no-code "mock-up" is the actual product. It happened with a job I did for the British Foreign and Commonwealth Office, when I showed the POC that took a few hours to knock together and they said, that's good enough, just put that demo into production as is. The scope was only a 7 day campaign. I see no-code as a peoples' config language that should basically replace the interface of devices like Android. Kids as young as 6 can understand stick and box dataflow diagrams. When "The diagram is the program", configuring things like privacy settings or app preferences might better be done in this domain. That doesn't make developers who use real languages obsolete.

alexpotato 4y ago

I 100% agree on the savings of real developer time when end users can self service. At the same time, I've also seen users do incredibly crazy things because either they didn't know any better or just didn't bother to "read the code". Good example of this is people just keep creating Statuses in JIRA until you end up with "Which of these 264 'Completed' statuses is the one I want?". It's similar to the Ops person "Hey, I wrote a Perl script that does what I want. Yay!" that turns out to be a spaghetti ball of copy/pasta. This is maybe less of a point about programming and more about governance. Either way, you will still need specialized people who make sure that everything is being done in some kind of guardrails.

alphager 4y ago
> At the same time, I've also seen users do incredibly crazy things because either they didn't know any better or just didn't bother to "read the code". Good example of this is people just keep creating Statuses in JIRA until you end up with "Which of these 264 'Completed' statuses is the one I want?". Why is this a problem? Programs are a means to an end. The 264 Jira statuses are messy and could be done away with, but would a clean solution actually change anything for the better? In a significant, "it was worth spending the money on a real developer" way?
- ElectricalUnion 4y ago
  > Why is this a problem? Programs are a means to an end. The 264 Jira statuses are messy and could be done away with, but would a clean solution actually change anything for the better? In a significant, "it was worth spending the money on a real developer" way? "Let's not waste money on a programmer so instead everyone in the company wastes millions of man-hours every month slowly filling things the wrong way!" There is a lesson here for ambitious system architects: the most dangerous enemy of a better solution is an existing codebase that is just good enough. - The Art of Unix Programming

lostboomerang 4y ago

> As someone who got their start in tech with a low-code environment (ServiceNow reporting) I have found the true value of low code is the ability for business/ops teams to create tools that serve their needs without waiting on a team of "real" developers to make time for them. This is because a lot of so-called "real developers" nowadays think their job is to keep up with the latest fads and finding ways of chopping the business needs in a way so they fit better to the popular framework of the day. Business quickly grow tired of hearing "that's not possible" when what the developer actually means "what you want to do is against the architecture of the framework I've decided we must use". If the business insist, the developer spends a lot of time fighting the framework. Now, from a job market perspective, it is entirely understandable that the developer prefers to do RDD - resume driven development. But it also makes it fully understandable that the business people wants to find ways of solving their needs, that do not include waiting on the "real developers". Hence the Excel and Access monstrosities present in every org.

nonrandomstring 4y ago

> the true value of low code is the ability for business/ ops teams to create tools that serve their needs without waiting on a team of "real" developers to make time for them. I agree with this. There is a hidden market that exists between "Developers" and "End Users". With Pure Data, I found this in the games and interactive audio industry where much of the procedural sound we made was done by "artists" essentially. Rapid prototyping using visual languages gave "good enough" code that could be exported to C/C++ later for embedding. Again I saw that with LabView in industrial modelling, where engineers who are not at all "expert" coders could work within their domain of expertise and spit out code (also through tools like Matlab/Octave and NetLogo) as basically a very advanced (demonstrably working) "requirements spec" to any developer who wanted to take it further. The win comes when you realise the lifetime of many rapid prototypes is good enough, and real developers are expensive enough, that the no-code "mock-up" is the actual product. It happened with a job I did for the British Foreign and Commonwealth Office, when I showed the POC that took a few hours to knock together and they said, that's good enough, just put that demo into production as is. The scope was only a 7 day campaign. I see no-code as a peoples' config language that should basically replace the interface of devices like Android. Kids as young as 6 can understand stick and box dataflow diagrams. When "The diagram is the program", configuring things like privacy settings or app preferences might better be done in this domain. That doesn't make developers who use real languages obsolete.