HIDDEN ISSUES With Low-Code Solutions

What are the kinds of issues software engineers come across when dealing with low-code solutions? Kevlin Henney & Dave Farley talk low code programming and the issues they take up with it.

-

📚 BOOKS:

-

🙏The Engineering Room series is SPONSORED BY EQUAL EXPERTS

___________________________________________

#softwareengineer #softwaredevelopment

[ScottKowalczyk]

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

[shyft]

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 😂

[Immudzen]

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.

[DomCim]

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

[HemalVarambhia]

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.

[alcarsharif]

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

[jimhumelsine]

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

[sirskaro]

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

[BonDeRado]

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.

[gunnarthorburn]

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.

[giuseppe.turitto]

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.

[jeffcauhape]

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.

[jimmyhirr]

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

[ChrisOvercash]

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.

[georgehelyar]

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.

[MJ-xljz]

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.

[rolandfisher]

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.

[yapdog]

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

[semosancus]

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.

[baka_baca]

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