Low-code makes the easy things easier and the hard things harder.

@Trezker

5 ай бұрын

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.

@maxron6514

5 ай бұрын

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.

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.

@TesterAnimal1

5 ай бұрын

I was told that in the 1980s.

@HemalVarambhia

5 ай бұрын

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 :).

@Brajgamer

3 ай бұрын

@@HemalVarambhia lol

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

@violin245

5 ай бұрын

This is a great take.

@chpsilva

5 ай бұрын

Surely can be used in this way, but unfortunately many customers will think this is good enough to production.

@fang_xianfu

3 ай бұрын

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.

low-code is hard to test and to debug. When low-code works everything is fine. When its not work then hell let loose.

One of the things I dislike most about the current state if the universe is that Excel is Turing Complete.

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.

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

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

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

@Axel_Andersen

5 ай бұрын

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.

You had me at Kevlin Henney, brilliant person and speaker on the tough and rough edges of programming.

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.

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.

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.

Who remembers scaling up an MS access project by backing it up with an MS SQL database with pass through queries? So hideous.

@Brajgamer

3 ай бұрын

I remember many visual basic softwares that I worked on.

But..... there is a button that shows the dependencies, even forward and backward 🙂

@bobwbarnes

3 ай бұрын

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!

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.

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.

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.

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.

@DF-wl8nj

5 ай бұрын

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.

When met with a no-code tech stack, I head straight for the scripting module. 😂

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.

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.

“Where is the function to show me dependent cells” Ctrl+] Ctrl+[ Is the answer…

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.

@Axel_Andersen

5 ай бұрын

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.

@cheetah100

5 ай бұрын

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

@Axel_Andersen

5 ай бұрын

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

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 find out from working with both that, low-code can serve as a map, but it can’t be the path.

Yes. Black boxes are scary!

@sighofman

3 ай бұрын

This lol

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.

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. kzread.info/dash/bejne/p6uOzJaRdpngmcY.html

David and Kevlin in the same conversation. that's the sort of situation I just shut up and listen.

0:47 I agree with you on this one

Apparently, these gentlemen haven't seen the latest suites of low-code/no-code offerings. :) They are speaking of the past, not the future.

@hBrynx

5 ай бұрын

Can you please name the offerings you're thinking of?

@newuser689

5 ай бұрын

ok

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

5 ай бұрын

The worst thing Microsoft ever created? You must not have used service fabric

@GackFinder

5 ай бұрын

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

@globalistgamer6418

5 ай бұрын

I mean...this is a highly, HIGHLY competitive field...

@GackFinder

5 ай бұрын

@@globalistgamer6418 What do you mean?

@globalistgamer6418

5 ай бұрын

The competition for being "the worst piece of utter trash that Microsoft has ever created".

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.

@azirious666

4 ай бұрын

Marketing agencies are there forever

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.

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 😅

Spread sheets are really really error prone! All spreadsheets of any moderate complexity will always have a significant error. (source: Panko)

@Axel_Andersen

5 ай бұрын

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

As long as the software industry does not understand software building is all about "The Message", everyone is just a noise.

High-level software languages themselves are "low-hardware" solutions with analogous strengths and pitfalls.

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.

(My settings say 1.00) I feel like this video is running at x1.25.

Nothing wrong with no or low code solution. The only issues is our assumptions about it.

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.

@caLLLendar

5 ай бұрын

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.

@SalihGoncu

5 ай бұрын

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

low code just to prototype

Kevin did not take his pills. He speaks too fast.😊

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.

Wordpress :D

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.

@ContinuousDelivery

5 ай бұрын

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.

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.