So they enable you to hire low wage workers to churn through simpler issues. And when you have harder issues to solve, hire veterans and don't force them to use the training wheels.
People who aren't programmers think the hard bit about software is all the typing. That's not the problem at all, the problem is complexity and finding structures that simplify rather than complicate an implementation. There are plenty of requirements that are simply better (clearer, more obvious, easier to change) when implemented as code vs implemented as (for example) flow diagrams. Its like saying the hard bit about writing a novel is learning English grammar, it completely misses the point 😂
My issue with low code systems is when they fail they fail in opaque ways that are very difficult to understand. I have deal with some low code machine learning systems and when they don't work they just don't work. You can't really look and see where the system went wrong or why. Instead your only real option is to build a new machine learning model yourself and figure out why the basic models don't work and fix them. In the end my experience with low code is that it doesn't save any time. You can get a prototype up quickly, it looks like it works in the beginning, but you find far too many failure points and there is no way to address them so you have to do all the work yourself anyways. Honestly, most of them look like scams designed to impress venture capitalists and hope they don't look behind the curtain.
I find low-code systems to be closer to the Business Analysis side of the process. It's a quick way to have a working prototype to put in front of product and process owners, especially important when they don't really know what they want
But the big risk is that these simple prototypes get promoted to be the real solution and then they're never replaced. My CTO says "incurring tech debt without a plan for how you're going to pay it off is actually tech theft" - and we're fortunate that these solutions really are temporary and prototypes.
Ironically, some years later, I worked for an organisation writing Ruby on Rails that it turned out was being integrated by that company I first worked for. At one point the situation got so desperate that if this integration wasn't successful, that company was going to go out of business! Coding is dead :).
I really appreciated this discussion👍 I would offer that the issue with Excel is actually not that it's "low-code." It's a specific solution that became more and more generalized over time, while the developers only focused on added functionality via formulae/scripts not user data access. You've given the proof in your Word example. I would also differ with you on your assessment that low-code as a generalized solution is a dead end. The reason you have that view is that you're programmers who love to write code. Further, the developers of those systems are just like you, but may also have a kind of condescending view of the user. Let's be real, though: all any of us are doing is manipulating data, computing values, and calling functions, all in some specific order. No more, no less. It's the layers of abstraction that make us feel superior, specifically achieving all of this through text interfaces. Because of this, we've made the development word a complete and utter mess. (webdev, anyone?) So, the problem isn't low-code. *We* (programmers) are the problem, over-glorifying what it is we actually do because we are in charge of the interface. Myself? I'm a programmer (3-decades of experience) who doesn't love to code. But I *am* highly visual. For the past several years I've been developing (in C) a generalized visual development system for people like me... visual people. However, it's malleable enough to allow for writing code in any language, even custom domain-specific ones. Maybe I'm arrogant in believing this, but I do believe that my visual development (non-bare metal) OS will change your mind. We'll see.......... (coding)...........
To be more applicable to software developers, this is the same thing that you get with "frameworks". Look how easy it is to do something simple, wow so easy. Now try to do anything slightly more complicated and you have to work out exactly how the framework works internally so that you can trick it into doing the thing you want it to do.
I think that low/no-code systems are closely related to Domain Specific Languages. They tend to present the DSL via a graphical UI rather than a text based language. DSLs can be great as long as the application remains with the specific domain. Drift out of that domain, even if the DSL technically supports it, and you'll be in for a world of hurt. If you define your own low/no/DSL coded solution, then you have the option to modify the DSL when you realize that you've omitted a domain concept that should be there. While a DSL can do domain specific code well, there are shortcomings/costs: * You're completely on your own. If you have an error in your DSL, you will have to fix it. * There is no testing environment for the DSL. If you want one, such as for your CI/CD pipeline, they you will have to develop it yourself. * There is no debugger, unless you develop it yourself. * There is no external support. No answers on Stack Overflow. Nothing to Google. No TH-cam Videos. * You're going to have to provide documentation, training, technical support, etc. * If the Low/No/DSL solution is configured by the user, and they introduce their own logic error, they will first accuse your code of having a bug in it.
So clearly argumented! Good work. As an aside I suspect that one of the reasons LISP never really became popular is that in my experience every LISP app seems to degrade (sorry the slur) to DSL based system ;)
Problem with spreadsheets is that there is no separation between data and program logic. If you make a copy of the data you make a copy of the "program" as well.
Besides the frustration of seeing people attempt serious data analysis using spreadsheets, there is the absolute horror of people trying to use them as a replacement for *databases* because they look superficially the same in some UI.
Great conversation, and wonderfully well explained. I can see the use of No/Low code or Spreadsheets as a way to prototype and give us a rough idea on where we will be going, the same way as clay or 3D printed models can be used to test design assumptions in the aerodynamics of a car or an airplane, but this will never substitute the real car or airplane at least the initial functional one. The issue is that once this prototype is ready most of the times the companies do not want to invest in the real product so we force users to ride in a Car that does not even have seats on it.. By the way stop overusing the animations is extremely distracting and causes a sense overload that makes me want to just have the audio version and forget about the video.
My first exposure to 4GLs was a programmer and user. I eventually worked for the company who made the one I used. I was surprised to discover that with the powerful tool we sold, our customers - the businesses - were able hire cheaper, less skilled programmers. Jobs are not defined in terms of what the employee can do, but in terms of the job that needs to be done. From that I see that Low Code -> Low Skill -> Low Pay.
i think at the heart of this we’re talking about human machine interfaces in general. i think it’s more of a composition or hierarchy than a spectrum, although that perspective is valid. the spectrum is in the goals we’re interested in when interfacing with those systems: how reproducible, maintainable, costly, easy to use or beginner friendly, etc do we want this solution to be? analysts who have never touched Python before may be better programmers than they realize, demanding ever more exotic features from Excel, but the next step toward better engineered solutions is SQL, Python, Pandas, Jupyter, and git, which seems like a huge gap of knowledge and experience and frankly a lot to ask of someone who isn’t a software engineer.
This. I SA a software tool that's low code and it's incredibly easy to tell people "Oh, just pick these options for your interface widget". If I tried to explain how to do the same validation in python, they would give me blank stares. That's despite it being objectively easier.
The problem with Excel is that you can avoid indicating your flow of thought (in Powerpoint, at least slide A comes before B, but in Excel you can put anything anywhere) and even avoid variable names, so spreadsheets from others can become a roller-coaster of detective work.
The one big advantage of low code is that you can layer over technology changes but changing the underlying code generator to target new languages or platforms.
Dietzler’s Law for Access: "Every Access project will eventually fail because, while 80% of what the user wants is fast and easy to create, and the next 10% is possible with difficulty, ultimately the last 10% is impossible because you can’t get far enough underneath the built-in abstractions, and users always want 100% of what they want."
The point of the success of the Spreadsheet is that it empowers users. While they do indeed have limitations, and are often misused, the reason is that it gives its users ownership and empowers them. The hubris of developers is that they feel the need to protect the perception of the superior intellect required to build code, rather than taking the example of the spreadsheet in building low code solutions.
You are right about the empowering part and 'success'. To me the problem is that most (say 99%) of people who do spreadsheets have no clue even the very basics of software development. Including but not limited to versioning, protecting the code, documentation, basic UI design etc. Add that to the fact that you cannot update the code in existing spreadsheet and it is left to the poor user to ensure that what he gets out of any spreadsheet is correct. Simple one page spreadsheet used to 'help' people to report their hourly billing or write their travel expenses, always horror shows. The way they calculate for example the duration of a business trip , guaranteed to have bugs so you have double check yourself. No instructions what you are supposed to enter where, take your hints from the titles which can be left, right, top or bottom of the field. One careless mistake and you destroy some 'code'. Send out N forms to be filled in by people and get back N differently abused forms, try collecting data from those.
@@Axel_Andersen I'm not saying we should be using spreadsheets, rather I see how spreadsheets got something right in terms of user empowerment. We have assumed the way developers work is the only way to work. The danger is that managers will use Spreadsheets because current software development is expensive, risky, and ends up in often brittle solutions. Most of all stakeholders don't feel ownership or control.
@@cheetah100 Yes, I'm not disagreeing. Just pointing out the other side of the coin ie what happens when people who do understand basic step into territory that they know little or nothing about. Spreadsheet are great PERSONAL tools, but as soon as you share your work you really should start to think about it like a developer, versioning, UI, protecting cells, documentation etc etc. Funny you should bring up the word 'brittle' ... that is exactly what most spreadsheets created by empowered USERS are: tehy work fine for the original user, not so much for the next guy.
Current low-code has issues. That cannot be denied. It keeps getting better, though. And, as you both chuckled about near the end, the path isn't to attempt complete solutions. It is to take pieces and make them great before taking on other pieces of the puzzle.
This line I read somewhere says it all for me: "The pain comes from people thinking it's going to replace developers, getting stuck, and then forcing the developers into the low-code tool too"
Just to quote the Captain of the Titanic. "Screw the icebergs, full speed ahead!" We all know the end result. It's the 90% below the surface that matters.
Interesting to equate spread sheets with "low code." Specifically with regard to spread sheets, I think "backwards compatibility" is actually that one accounting professional who learned back with VisiCalc and if you change the way anything works, his (it's probably "his") knowledge goes out the window and he can't work anymore. So now he's promoted to be in charge of everything, and if you change it he'll throw out your software and use something else that works like it did back in 1985.
I've been working with Microsofts low-code "solution" Azure Logic Apps for over a year now. It's the worst piece of utter trash that Microsoft has ever created, bar none. Total cost of development and total cost of ownership is _easily_ 10x that of a corresponding coded module. You cannot run it reliably locally, it is fundamentally untestable, there is no CI/CD pipeline for it that actually works properly, it's extremely slow performance wise, doesn't scale whatsoever, isn't versioned, has hidden temporal issues, its UI is extremely buggy (I find new bugs every week), logging doesn't work properly (and Microsoft refuses to acknowledge there even is an issue with logging). Also, it has the added negative effect that citizen developers, i.e. people that should NOT be anywhere near applications that are critical to production, can edit these applications LIVE. It's absolute madness, and literally the only person getting rich on this is me, since I happen to charge my client by the hour.
@@georgehelyar As a matter of fact, I have used Service Fabric. Yes, it sucks, and yes, I'm glad I never had to use it for anything important. But it's nowhere close to the suckage factor you get with Azure Logic Apps. You can run Service Fabric locally. You can write unit tests for it. And since it's code, it's effectively off limits for citizen developers who don't know what they're doing. The opposite is true for Logic Apps.
Low code tools solve a different type of business problem than traditional coding solves. First, Low code solves the problem that there're to few developers available, so these tools are developed to be closer to the business side. Therefore you have to set up appropriate Governance to pick the correct IT solution for the problem. Secondly, you cannot generalize Low code solutions, each tool has different levels of 'low code' in specific areas of the stack. Each problem needs thorough analysis to pick the correct IT solution, which also means that the presence of other IT solutions also influences the application scope of low code, but the same argument applies for all IT solutions provided by IT in a company.
The problem with modern software development is early domain binding. We begin with an analysis of the domain and create a foundational data structure. From there we build the code on top pf the data structure. The domain gets burnt into the code, at which point the domain is coupled to the code, making it difficult to modify. What if we aimed to decouple from the domain, and rather treat it more like something close to configuration? This already exists somewhat with SQL databases which have configured schema. What if you had systems like SQL that were configuration based? Perhaps allow code expression where it makes sense; I'm not saying eliminate all code. th-cam.com/video/uwZj4XF6zic/w-d-xo.html
A famous economics paper was discovered to have a simple spreadsheet error that reversed its conclusions. The paper was used to justify austerity in the 2010s, and thus this Excel error contributed to the misery, ill-health and even death of thousands and thousands of people. Growth in a Time of Debt, Reinhart and Rogoff 2010.
I think no-code is also a way for startups with non-technical founders to launch an MVP quickly and start pitching their idea for maybe a seed round. Then they can start building with code. Some nocode platforms will allow you to do this in stages (e.g migrate backend functionality first then front-end). The mistake would be to stay in the no-code forever or even for too long.
One little thing: Excel is keeping the world safe because USMIL and NATO are using it for logistics big time. It's kind of the ideal tool: simple, powerful enough, generates reports, and is 100% US manufactured by a company with a long and impeccable track record of cooperation with the DoD. That's not nothing. Of course, the tabular form makes it a nightmare for a lot of things that are not military logistics 😅
In my experience most single page spreadsheets have errors because they are created by people who have no clue of even the very basics of software development. Including versioning, cell protection, documentation, basic UI design etc.
If you do not know what you want to do, low code or machine code won't help you. If you know what you want to do, machine code isn't a lot harder to learn than any no-code solutions you have out there.
You should edit your comment again. "Machine code"? I think you mean "programming language". And, learning programming languages is very difficult. I am developing a solution that helps people avoid learning the common programming languages.
@@caLLLendar learning no programming language is difficult. It may be difficult for people with short attention span, but not any more difficult than the mathematics that we learn at school. Whoever was able to finish the High school curriculum with acceptable grade can learn any programming language, even the machine code with ease.
im part of a team working on a low code platform (should release in beta soon) that merges the advantages (quick solution design) with the disadvantages (lack of adjustment capability and precision) into a solution that allows for both with, in the future version, AI capability to interpret requirements and generate the code directly from that with adjustment capability through stories and their tasks.
This discussion. is a little infuriating. Are we talking about actual low-code solutions or Excel? As the author of a low code (integration) solution they are different. I understand some frustrations of low-code and the limits on where we would deploy our solution - but ultimately low code solutions should … 1. Be able to debug/trace. 2. Speed evolution and deployment of the task (it's attempting to abstract/simplify). 3. Be applicable to a broad range of use cases - about ~ 95% of its purported functionality. We have numerous customers/partners whom have automated large swathes of processes using our software - this would have been out of reach as they did not have an inhouse development team. Will low code be able to solve your high volume API requirements - probably not - but processing 10k documents per day - absolutely.
Low-code systems are not for software engineers to analyze. All the arguments are under assumption that a software engineer has to analyze the low-code system just like a normal one. This, IMHO, is a flawed thinking. SE should not use the low-code and expect the same familiarity.
The engineering part that Kevlin and I are discussing, is not about the analysis of there problem as much as the approach to working on it. Low code systems generally promote an overly naive way of working, where we willl get things right first time, and the system won't need to be revisited and changed in future. As soon as you factor these things in the real "engineering of solutions" then Lo-code is less appealing.. Where is the version control, where is the testing, where is the data migration etc etc etc.
11 หลายเดือนก่อน
Kevin did not take his pills. He speaks too fast.😊
This feels a bit elitist to me, Dave 🤨 It seems to hinge on the assumption that a tool has to be completely generalizable before it can be called useful. We can criticize Excel and spreadsheets all day for their limitations as a solution for complex problems, but isn't their ubiquitousness proof that they're at least good enough for a multitude of problems that are not that complex? And the same is true of low-code tools, I'd think - no you can't build an operating system with them, but the vast majority of software problems are simple CRUD or LOB automations that they solve very adequately, more complex than what excel can do but still not so complex that a whole versioning/testing/deployment infrastructure is required.
Low-code makes the easy things easier and the hard things harder.
So they enable you to hire low wage workers to churn through simpler issues. And when you have harder issues to solve, hire veterans and don't force them to use the training wheels.
I am responsible for a lowcode Tool in a big Company and this is exactly What i d answer to anyone asking to describe lowcode in one sentence.
People who aren't programmers think the hard bit about software is all the typing. That's not the problem at all, the problem is complexity and finding structures that simplify rather than complicate an implementation.
There are plenty of requirements that are simply better (clearer, more obvious, easier to change) when implemented as code vs implemented as (for example) flow diagrams.
Its like saying the hard bit about writing a novel is learning English grammar, it completely misses the point 😂
My issue with low code systems is when they fail they fail in opaque ways that are very difficult to understand. I have deal with some low code machine learning systems and when they don't work they just don't work. You can't really look and see where the system went wrong or why. Instead your only real option is to build a new machine learning model yourself and figure out why the basic models don't work and fix them.
In the end my experience with low code is that it doesn't save any time. You can get a prototype up quickly, it looks like it works in the beginning, but you find far too many failure points and there is no way to address them so you have to do all the work yourself anyways.
Honestly, most of them look like scams designed to impress venture capitalists and hope they don't look behind the curtain.
I find low-code systems to be closer to the Business Analysis side of the process. It's a quick way to have a working prototype to put in front of product and process owners, especially important when they don't really know what they want
This is a great take.
Surely can be used in this way, but unfortunately many customers will think this is good enough to production.
But the big risk is that these simple prototypes get promoted to be the real solution and then they're never replaced. My CTO says "incurring tech debt without a plan for how you're going to pay it off is actually tech theft" - and we're fortunate that these solutions really are temporary and prototypes.
My first private sector role was using Appian's BPM platform. The CEO told me "Coding's dead, man!" This was in 2010, and I'm still waiting.
I was told that in the 1980s.
Ironically, some years later, I worked for an organisation writing Ruby on Rails that it turned out was being integrated by that company I first worked for. At one point the situation got so desperate that if this integration wasn't successful, that company was going to go out of business! Coding is dead :).
@@HemalVarambhia lol
low-code is hard to test and to debug. When low-code works everything is fine. When its not work then hell let loose.
I really appreciated this discussion👍 I would offer that the issue with Excel is actually not that it's "low-code." It's a specific solution that became more and more generalized over time, while the developers only focused on added functionality via formulae/scripts not user data access. You've given the proof in your Word example.
I would also differ with you on your assessment that low-code as a generalized solution is a dead end. The reason you have that view is that you're programmers who love to write code. Further, the developers of those systems are just like you, but may also have a kind of condescending view of the user. Let's be real, though: all any of us are doing is manipulating data, computing values, and calling functions, all in some specific order. No more, no less. It's the layers of abstraction that make us feel superior, specifically achieving all of this through text interfaces. Because of this, we've made the development word a complete and utter mess. (webdev, anyone?)
So, the problem isn't low-code. *We* (programmers) are the problem, over-glorifying what it is we actually do because we are in charge of the interface. Myself? I'm a programmer (3-decades of experience) who doesn't love to code. But I *am* highly visual. For the past several years I've been developing (in C) a generalized visual development system for people like me... visual people. However, it's malleable enough to allow for writing code in any language, even custom domain-specific ones. Maybe I'm arrogant in believing this, but I do believe that my visual development (non-bare metal) OS will change your mind. We'll see.......... (coding)...........
One of the things I dislike most about the current state if the universe is that Excel is Turing Complete.
To be more applicable to software developers, this is the same thing that you get with "frameworks".
Look how easy it is to do something simple, wow so easy.
Now try to do anything slightly more complicated and you have to work out exactly how the framework works internally so that you can trick it into doing the thing you want it to do.
I think that low/no-code systems are closely related to Domain Specific Languages. They tend to present the DSL via a graphical UI rather than a text based language.
DSLs can be great as long as the application remains with the specific domain. Drift out of that domain, even if the DSL technically supports it, and you'll be in for a world of hurt.
If you define your own low/no/DSL coded solution, then you have the option to modify the DSL when you realize that you've omitted a domain concept that should be there.
While a DSL can do domain specific code well, there are shortcomings/costs:
* You're completely on your own. If you have an error in your DSL, you will have to fix it.
* There is no testing environment for the DSL. If you want one, such as for your CI/CD pipeline, they you will have to develop it yourself.
* There is no debugger, unless you develop it yourself.
* There is no external support. No answers on Stack Overflow. Nothing to Google. No TH-cam Videos.
* You're going to have to provide documentation, training, technical support, etc.
* If the Low/No/DSL solution is configured by the user, and they introduce their own logic error, they will first accuse your code of having a bug in it.
So clearly argumented! Good work. As an aside I suspect that one of the reasons LISP never really became popular is that in my experience every LISP app seems to degrade (sorry the slur) to DSL based system ;)
Problem with spreadsheets is that there is no separation between data and program logic. If you make a copy of the data you make a copy of the "program" as well.
Besides the frustration of seeing people attempt serious data analysis using spreadsheets, there is the absolute horror of people trying to use them as a replacement for *databases* because they look superficially the same in some UI.
Great conversation, and wonderfully well explained. I can see the use of No/Low code or Spreadsheets as a way to prototype and give us a rough idea on where we will be going, the same way as clay or 3D printed models can be used to test design assumptions in the aerodynamics of a car or an airplane, but this will never substitute the real car or airplane at least the initial functional one.
The issue is that once this prototype is ready most of the times the companies do not want to invest in the real product so we force users to ride in a Car that does not even have seats on it..
By the way stop overusing the animations is extremely distracting and causes a sense overload that makes me want to just have the audio version and forget about the video.
My first exposure to 4GLs was a programmer and user. I eventually worked for the company who made the one I used. I was surprised to discover that with the powerful tool we sold, our customers - the businesses - were able hire cheaper, less skilled programmers. Jobs are not defined in terms of what the employee can do, but in terms of the job that needs to be done. From that I see that Low Code -> Low Skill -> Low Pay.
You had me at Kevlin Henney, brilliant person and speaker on the tough and rough edges of programming.
i think at the heart of this we’re talking about human machine interfaces in general. i think it’s more of a composition or hierarchy than a spectrum, although that perspective is valid. the spectrum is in the goals we’re interested in when interfacing with those systems: how reproducible, maintainable, costly, easy to use or beginner friendly, etc do we want this solution to be?
analysts who have never touched Python before may be better programmers than they realize, demanding ever more exotic features from Excel, but the next step toward better engineered solutions is SQL, Python, Pandas, Jupyter, and git, which seems like a huge gap of knowledge and experience and frankly a lot to ask of someone who isn’t a software engineer.
This. I SA a software tool that's low code and it's incredibly easy to tell people "Oh, just pick these options for your interface widget". If I tried to explain how to do the same validation in python, they would give me blank stares. That's despite it being objectively easier.
I think one of the things that got me into software was back in the early 1980s was that it seemed to involve a very large quantity of squared paper.
The problem with Excel is that you can avoid indicating your flow of thought (in Powerpoint, at least slide A comes before B, but in Excel you can put anything anywhere) and even avoid variable names, so spreadsheets from others can become a roller-coaster of detective work.
The one big advantage of low code is that you can layer over technology changes but changing the underlying code generator to target new languages or platforms.
But..... there is a button that shows the dependencies, even forward and backward 🙂
Yes indeed - I think a problem is training - its got the tools but not everyone knows that! - Its still not great when the spreadsheet gets complex!
Dietzler’s Law for Access: "Every Access project will eventually fail because, while 80% of what the user wants is fast and easy to create, and the next 10% is possible with difficulty, ultimately the last 10% is impossible because you can’t get far enough underneath the built-in abstractions, and users always want 100% of what they want."
The point of the success of the Spreadsheet is that it empowers users. While they do indeed have limitations, and are often misused, the reason is that it gives its users ownership and empowers them. The hubris of developers is that they feel the need to protect the perception of the superior intellect required to build code, rather than taking the example of the spreadsheet in building low code solutions.
You are right about the empowering part and 'success'. To me the problem is that most (say 99%) of people who do spreadsheets have no clue even the very basics of software development.
Including but not limited to versioning, protecting the code, documentation, basic UI design etc.
Add that to the fact that you cannot update the code in existing spreadsheet and it is left to the poor user to ensure that what he gets out of any spreadsheet is correct.
Simple one page spreadsheet used to 'help' people to report their hourly billing or write their travel expenses, always horror shows.
The way they calculate for example the duration of a business trip , guaranteed to have bugs so you have double check yourself.
No instructions what you are supposed to enter where, take your hints from the titles which can be left, right, top or bottom of the field.
One careless mistake and you destroy some 'code'. Send out N forms to be filled in by people and get back N differently abused forms, try collecting data from those.
@@Axel_Andersen I'm not saying we should be using spreadsheets, rather I see how spreadsheets got something right in terms of user empowerment. We have assumed the way developers work is the only way to work. The danger is that managers will use Spreadsheets because current software development is expensive, risky, and ends up in often brittle solutions. Most of all stakeholders don't feel ownership or control.
@@cheetah100 Yes, I'm not disagreeing. Just pointing out the other side of the coin ie what happens when people who do understand basic step into territory that they know little or nothing about. Spreadsheet are great PERSONAL tools, but as soon as you share your work you really should start to think about it like a developer, versioning, UI, protecting cells, documentation etc etc. Funny you should bring up the word 'brittle' ... that is exactly what most spreadsheets created by empowered USERS are: tehy work fine for the original user, not so much for the next guy.
Current low-code has issues. That cannot be denied. It keeps getting better, though. And, as you both chuckled about near the end, the path isn't to attempt complete solutions. It is to take pieces and make them great before taking on other pieces of the puzzle.
Who remembers scaling up an MS access project by backing it up with an MS SQL database with pass through queries? So hideous.
I remember many visual basic softwares that I worked on.
This line I read somewhere says it all for me: "The pain comes from people thinking it's going to replace developers, getting stuck, and then forcing the developers into the low-code tool too"
Just to quote the Captain of the Titanic. "Screw the icebergs, full speed ahead!" We all know the end result. It's the 90% below the surface that matters.
When met with a no-code tech stack, I head straight for the scripting module. 😂
Interesting to equate spread sheets with "low code." Specifically with regard to spread sheets, I think "backwards compatibility" is actually that one accounting professional who learned back with VisiCalc and if you change the way anything works, his (it's probably "his") knowledge goes out the window and he can't work anymore. So now he's promoted to be in charge of everything, and if you change it he'll throw out your software and use something else that works like it did back in 1985.
I've been working with Microsofts low-code "solution" Azure Logic Apps for over a year now. It's the worst piece of utter trash that Microsoft has ever created, bar none. Total cost of development and total cost of ownership is _easily_ 10x that of a corresponding coded module. You cannot run it reliably locally, it is fundamentally untestable, there is no CI/CD pipeline for it that actually works properly, it's extremely slow performance wise, doesn't scale whatsoever, isn't versioned, has hidden temporal issues, its UI is extremely buggy (I find new bugs every week), logging doesn't work properly (and Microsoft refuses to acknowledge there even is an issue with logging). Also, it has the added negative effect that citizen developers, i.e. people that should NOT be anywhere near applications that are critical to production, can edit these applications LIVE. It's absolute madness, and literally the only person getting rich on this is me, since I happen to charge my client by the hour.
The worst thing Microsoft ever created? You must not have used service fabric
@@georgehelyar As a matter of fact, I have used Service Fabric. Yes, it sucks, and yes, I'm glad I never had to use it for anything important. But it's nowhere close to the suckage factor you get with Azure Logic Apps. You can run Service Fabric locally. You can write unit tests for it. And since it's code, it's effectively off limits for citizen developers who don't know what they're doing. The opposite is true for Logic Apps.
I mean...this is a highly, HIGHLY competitive field...
@@globalistgamer6418 What do you mean?
The competition for being "the worst piece of utter trash that Microsoft has ever created".
“Where is the function to show me dependent cells”
Ctrl+]
Ctrl+[
Is the answer…
I find out from working with both that, low-code can serve as a map, but it can’t be the path.
Low code tools solve a different type of business problem than traditional coding solves. First, Low code solves the problem that there're to few developers available, so these tools are developed to be closer to the business side. Therefore you have to set up appropriate Governance to pick the correct IT solution for the problem. Secondly, you cannot generalize Low code solutions, each tool has different levels of 'low code' in specific areas of the stack.
Each problem needs thorough analysis to pick the correct IT solution, which also means that the presence of other IT solutions also influences the application scope of low code, but the same argument applies for all IT solutions provided by IT in a company.
Yes. Black boxes are scary!
This lol
The problem with modern software development is early domain binding. We begin with an analysis of the domain and create a foundational data structure. From there we build the code on top pf the data structure. The domain gets burnt into the code, at which point the domain is coupled to the code, making it difficult to modify. What if we aimed to decouple from the domain, and rather treat it more like something close to configuration? This already exists somewhat with SQL databases which have configured schema. What if you had systems like SQL that were configuration based? Perhaps allow code expression where it makes sense; I'm not saying eliminate all code. th-cam.com/video/uwZj4XF6zic/w-d-xo.html
A famous economics paper was discovered to have a simple spreadsheet error that reversed its conclusions. The paper was used to justify austerity in the 2010s, and thus this Excel error contributed to the misery, ill-health and even death of thousands and thousands of people. Growth in a Time of Debt, Reinhart and Rogoff 2010.
David and Kevlin in the same conversation. that's the sort of situation I just shut up and listen.
Apparently, these gentlemen haven't seen the latest suites of low-code/no-code offerings. :) They are speaking of the past, not the future.
Can you please name the offerings you're thinking of?
ok
I think no-code is also a way for startups with non-technical founders to launch an MVP quickly and start pitching their idea for maybe a seed round.
Then they can start building with code. Some nocode platforms will allow you to do this in stages (e.g migrate backend functionality first then front-end).
The mistake would be to stay in the no-code forever or even for too long.
Marketing agencies are there forever
One little thing: Excel is keeping the world safe because USMIL and NATO are using it for logistics big time.
It's kind of the ideal tool: simple, powerful enough, generates reports, and is 100% US manufactured by a company with a long and impeccable track record of cooperation with the DoD.
That's not nothing.
Of course, the tabular form makes it a nightmare for a lot of things that are not military logistics 😅
High-level software languages themselves are "low-hardware" solutions with analogous strengths and pitfalls.
0:47 I agree with you on this one
As long as the software industry does not understand software building is all about "The Message", everyone is just a noise.
Spread sheets are really really error prone! All spreadsheets of any moderate complexity will always have a significant error. (source: Panko)
In my experience most single page spreadsheets have errors because they are created by people who have no clue of even the very basics of software development.
Including versioning, cell protection, documentation, basic UI design etc.
Interesting conversation, thanks.
Nauseating background -- please don't...!
If you do not know what you want to do, low code or machine code won't help you. If you know what you want to do, machine code isn't a lot harder to learn than any no-code solutions you have out there.
You should edit your comment again.
"Machine code"? I think you mean "programming language".
And, learning programming languages is very difficult.
I am developing a solution that helps people avoid learning the common programming languages.
@@caLLLendar learning no programming language is difficult. It may be difficult for people with short attention span, but not any more difficult than the mathematics that we learn at school. Whoever was able to finish the High school curriculum with acceptable grade can learn any programming language, even the machine code with ease.
im part of a team working on a low code platform (should release in beta soon) that merges the advantages (quick solution design) with the disadvantages (lack of adjustment capability and precision) into a solution that allows for both with, in the future version, AI capability to interpret requirements and generate the code directly from that with adjustment capability through stories and their tasks.
Nothing wrong with no or low code solution. The only issues is our assumptions about it.
This discussion. is a little infuriating. Are we talking about actual low-code solutions or Excel? As the author of a low code (integration) solution they are different. I understand some frustrations of low-code and the limits on where we would deploy our solution - but ultimately low code solutions should …
1. Be able to debug/trace.
2. Speed evolution and deployment of the task (it's attempting to abstract/simplify).
3. Be applicable to a broad range of use cases - about ~ 95% of its purported functionality.
We have numerous customers/partners whom have automated large swathes of processes using our software - this would have been out of reach as they did not have an inhouse development team. Will low code be able to solve your high volume API requirements - probably not - but processing 10k documents per day - absolutely.
(My settings say 1.00) I feel like this video is running at x1.25.
Low-code systems are not for software engineers to analyze. All the arguments are under assumption that a software engineer has to analyze the low-code system just like a normal one.
This, IMHO, is a flawed thinking. SE should not use the low-code and expect the same familiarity.
The engineering part that Kevlin and I are discussing, is not about the analysis of there problem as much as the approach to working on it. Low code systems generally promote an overly naive way of working, where we willl get things right first time, and the system won't need to be revisited and changed in future. As soon as you factor these things in the real "engineering of solutions" then Lo-code is less appealing.. Where is the version control, where is the testing, where is the data migration etc etc etc.
Kevin did not take his pills. He speaks too fast.😊
low code just to prototype
This feels a bit elitist to me, Dave 🤨 It seems to hinge on the assumption that a tool has to be completely generalizable before it can be called useful.
We can criticize Excel and spreadsheets all day for their limitations as a solution for complex problems, but isn't their ubiquitousness proof that they're at least good enough for a multitude of problems that are not that complex? And the same is true of low-code tools, I'd think - no you can't build an operating system with them, but the vast majority of software problems are simple CRUD or LOB automations that they solve very adequately, more complex than what excel can do but still not so complex that a whole versioning/testing/deployment infrastructure is required.
Wordpress :D