Low code is no replacement for software development, say German-speaking SAP users

SAP users have voiced concerns about the German enterprise application vendor's latest "low-code" offering, saying the company had yet to show the level of "process depth" it could demonstrate. At TechEd last week, SAP introduced SAP Build, the latest iteration of its low-code concept designed to provide an environment to give …

[Filippo]

Whenever I read about low-code or no-code, I find that all of the praise comes from the people who are making these platforms, or, sometimes, from people who are tinkering with them, or learning to use them, or planning to use them.

Praise from people who actually use them in production is conspicuosly absent.

I also notice a remarkable number of caveats about things it doesn't replace, and not very many mentions of things it does replace.

[Prst. V.Jeltz]

I've used low code

It absolutely sucks balls, I spent 2 days and calls to the vendor trying to figure out how the fuck to do the equivalent of:

variable01 = true;

"Low code" just appeals to non programmers who are not in a position to judge what the easiest method of programming a given task will be.

It also means you spend 90% of the time learning that particular system's completeyly unintuitive methodology of dragging and dropping shit and are limited to what the software's task as , unlike a real language which can do anything.

I'll do my coding in a text editor thanks very much (one that makes the code all pretty colours)

[withQuietEyes]

They're completely insane! And the people making them aren't thinking like programmers, so nothing's ever documented, and it seems like they just slap features together so they can sell their system as "API-capable" or whatever buzzwords they think will sell, without checking if they're actually usable in any coherent way. The amount of time I spent trying to just get a single, basic GET to run and display...

[Anonymous Coward]

Exactly. Like the low code solution that was sold to us, MatSoft. It is shit. It breaks all database standards and does it their way. So if you know databases its VERY confusing to use. What's worse, spend months learning it and then look for a job elsewhere and you find no one else uses it, so there are no jobs available to take that learning on.

We were sold it as "so easy to use each department could have one user using it to create apps" that was a lie. Turned out to be complicated enough that was never going to happen. The powers that be that wanted that also wanted that one person in the department to also do their day job. So they were essentially going to pay them to be a document scanner (low wage) but also make them be a developer but not pay them the wage a developer would get.

Its all a scam. In the early days the council won awards for their new digital apps. Apps that hadn't actually been created.

All shady.

[Dr Who]

Low code in essence is just another level of abstraction from machine code - a very high level language if you like.

The art of programming though is a way of thinking, a mental approach more than a particular language. Ask a business person to define the process or problem they need solving or automating, and inevitably you'll get a vague, poorly specified, ill thought through answer. Your next step is to tease of them what they're actually after, and make them aware of the knock on effects of what they're asking for. It's the classic beginners exercise of writing down how to make a cup of tea. Most non-programmers miss several of the crucial steps.

No matter how high level the language, you still need to think like a programmer to make the machines do useful stuff. Putting amateurs and hobbyists in charge will inevitably lead to a mess of a system and most likely the loss or corruption of valuable data.

[Roland6]

Programming is just a small, but important part of software development - just like bricklaying is a small but important part of construction.

Low-code doesn't remove the need to think about the problem and design and implement in a structured and maintainable way, otherwise you are simply back to the business critical spreadsheet some user knocked up and thus is flying under the radar.

[_olli]

The false assumption behind "low code" is that the hard thing in software development would be writing text, and thus low-code tools attempt to resolve difficulty of software development by taking away that writing-of-text part.

Which of course is not the difficult part at all. Source code lexicons are almost a trivial part of the challenge, so that a sharp 11 year old with textbook or tutorial site can teach him/herself the rules required for writing syntactically correct source code.

[Potemkine!]

Ask a business person to define the process or problem they need solving or automating, and inevitably you'll get a vague, poorly specified, ill thought through answer.

They should not define how it should be automated. What they should define is the problem they have, not what the solution should be. Too often users think in term of 'how' instead of 'why', and it's the job of IT to make them think in term of 'why' instead of 'how'. This should be the base of an expression of needs on which both business and IT should agree, as a contract between them. In an ideal world, this expression wouldn't mention the technical solution to that problem. The solution should come later from the designer, who should ensure the solution fits well the expression of needs.

Understand users needs is an art which should be taught in IT schools.

== Bring us Dabbsy back! ==

[P_Jamez]

Very rarely have I met a developer that is able to communicate with the business side clearly enough that both sides understand each other and clearly understand what the problem is, hence, I have made a career of sitting in between both parties, as a business analyst, translating.

[Mike 137]

Could not be more right!

"The art of programming though is a way of thinking, a mental approach more than a particular language"

Thanks a million -- absolutely spot on. But now almost everyone is taught "coding" (if taught anything at all other than just the knobs and levers of some proprietary dev environment) rather than programming, that truth has been largely forgotten, even by the developer community.

[doublelayer]

Re: Could not be more right!

I don't think starting with coding necessarily means eliminating the thinking, and in fact doing it the other way around may not work. You need some understanding of how something can be done before you can successfully implement the solution, so learning what code does and where some limits are helps when teaching how to solve a problem with it. If you start with problem solving, you have to talk in generalities. You could say "there are limited resources so be aware of what you have to use efficiently and what you can waste harmlessly", but if they've been taught about the mechanics, you can give useful examples like showing them how much certain things use in RAM or CPU time and demonstrating how those limits come into play. You need to learn both, but practical details help give non-theoretical examples that can help get the lessons understood.

[Strahd Ivarius]

Re: Could not be more right!

It has been like that for a minimum of 20 years now.

I still remember a day where I was supposed to work on implementing a system, alongside 2 junior programmers.

I was the only one to read all the specification document before even trying to code, so I spotted that at a place it was stated A, and a few pages latter non-A.

Going to the specs writer with my findings, he had to request an immediate stop to the coding until he rewrote the specs...

(it took long enough that I left the company before it came back corrected)

And a few years before one of my client had a process in place since years that had the same kind of A / non-A situation, never having spotted the issue before I asked what I was supposed to do when implementing a new system...

It took them 2 weeks with numerous meetings to decide.

[Gene Cash]

Or as the quote goes: "The reason programming is hard is because you must clearly and unambiguously state what you want to have happen. Irreducible complexity is irreducible."

[ChoHag]

> Putting amateurs and hobbyists in charge will inevitably lead to a mess of a system and most likely the loss or corruption of valuable data.

See: DevOps.

[Novex]

Still Generic

Low code always seems to be about generic business needs, and it never seems to allow digging in to the code to allow modifications to that code that are often needed by very specific business needs. As such there's always some demand for actual coding even on the business side of the 'I.T. Wall' to be able to get solutions put together to meet very particular business requirements.

[Triggerfish]

Re: Still Generic

I agree here, I like using power automate TBH, its very useful for some things and it slots in nicely with office and so on, and its the same with things like connectors. Some of them are really useful, some of them are great for the average user.

But they are blocks of code that do a very specific thing, yes you can tweak them and play around a bit. But you can almost end up having to spend as much time figuring out something as it would to actually have someone write some code, and anyone diving that deeply into tweaking it is probably not the average office user low code is aimed at anyway.

Once you start to go past a certain point of complexity, it's either not possible to build it with these blocks or it becomes a monstrosity of hacks cobbled together just waiting to fall over.

[Fred Daggy]

Bah Humbug

Inevitably if end users are given the chance to automate something, it is only a trivial few out of thousands that will spend the time to do it.

Reason: they just want to get it done and move on to the next thing. Sort of like IT staff, really. Even if, over the long hall it could be done and result in a net time saving. Time is of the essence.

Most of the time, its one person with one itch to scratch. Once the business realises they can save time, THEN, there is some chance the process might be started. But, never, ever, will it be end users themselves doing it, they will palm it off to IT.

Picking up a new skill, like coding, is something only driven by business imperative. For some, even thinking logically like this is a new field. And for a great many, thinking is something new. If you think users will flock to low-code solutions, ask yourself "How many users still manually add up columns of data in Excel".

[Anonymous Coward]

Re: manually add up

It never harms to check what Excel is doing.

I've got a sheet here that tells me 17 November 2022 divided by Avogadro's number (6.02E-34) plus £1.75 is equal to 7.45301E+37. I'm not quite sure what units that should be in though.

Many business activities are subject to quality assurance processes ("what is it intended to do? how should it be used? does it work correctly with normal and unexpected inputs? how can you be sure?"). Is this Low Coding passing those tests, or bypassing them?

[Anonymous Coward]

Re: Units

Well gosh darn it, no-one spotted the deliberate mistake - Avogadro's number is 6.02E+23, I must have been mixing it up with Planck's constant again. Still, what's 57 orders of magnitude between friends on a Friday afternoon, with the World Cup on!

Anyway Dimensional Consistency Engines are meant to be broken, how else are we going to get new Dr Who plots?

[Richard 12]

Re: manually add up

I wish Excel would pay attention to units.

It would avoid a great many stupid business ending mistakes.

[OhForF']

Re: manually add up

A ton of problems in excel are caused by excel attempting to automatically figure out if the data is a string or a number or a date and users being unable or unwilling to check it was interpreted correctly. Excel attempting to automatically assign units to values in data cells will only complicate things. User's won't be willing to assign a unit manually.

I'd welcome a change that forces excel users to define the data and format to be used in a cell (not allowing wildcard/variant types) before using it but I'm pretty sure that is not something a majority of current users would accept.

[katrinab]

Re: manually add up

And if you originally created the spreadsheet on a Mac, using the 1904 date system, it will give a different answer, even if you subsequently run the spreadsheet in Windows.

[trevorde]

Deja vu all over again

Isn't this just CASE tools for the 20's?

https://en.wikipedia.org/wiki/Computer-aided_software_engineering

[Martin]

Re: Deja vu all over again

Or even The Last One from 1981.

I've retired now, but I spent nearly forty years writing software, and I never saw any sign that it's going to be replaced with some magic that will allow end users to write software without knowing what they are doing. And I'd bet that anyone starting a new career in software this year will still have a job in twenty years time.

[David Hicklin]

Re: Deja vu all over again

>> users to write software without knowing what they are doing

23rd or 24th century when users will be able to simply talk to the computer ala Star Trek

[Plest]

Well bugger me!

Imagine that, doing something properly with the right mindset, proper experience, then using both the correct and flexible tools and materilals, will result in a much better outcome! Well who'd a thunk it!

[Anonymous Coward]

Here's my theory.

Coding is unusual in that non-(ex-)technical managers don't have the foggiest clue about what's involved, as 90% or more of software is invisible. As a counterexample, even a layperson knows you don't build a house by starting with putting the roof on. But the equivalent intuitions are not present for software.

Even many business functions, while specialised and difficult, a manager might think they at least know what's going on in logo design, or bookkeeping, or cold calling customers, or assembling a contract from boilerplate. But creating software is totally foreign to them.

I think that makes managers feel out of control, as it makes their technical staff relatively powerful compared to most staff.

That's how these low code "citizen developer" things arise. They sell, not to engineers who would be after a better tool, but to managers, who want to feel in control. And, coincidentally, who are the ones with the budget to spend, and the time to drip-feed the idea into more senior managers' heads for approval.

[OhForF']

a manager might think they at least know what's going on in ... or assembling a contract from boilerplate

I am pretty sure the companies law experts have the same thoughts about a mangler thinking he knows what's going on changing a contract as database administrators about the (self declared db expert) manager doing "database management".

[thondwe]

Support and Maintenance

Ask any lo-code supplier about things like Source control to help with long term support and maintenance by skilled programmers, rather than Excel/Access level local end user "hacks" and they'll like as not run away!

[Strahd Ivarius]

Re: Support and Maintenance

Don't forget also: who is the owner of that no-code?

As: who can modify the no-code processes once it is in place, and especially who will be able to do it when the "creator" leaves the company?

[Anonymous Coward]

visual scripting isn't new...

Visual scripting aka no code is just visual programming though menu's rather than typing it out. I don't really see any difference except the interface for interacting with the software.

Most of the problems with no code are down to them being vendor lockin solutions rather than software solutions which leads to a lack fo flexibility and having no ability to write your own tooling this causes a lack of testability, difficult release process and problems with the ability to do hoxfixes .

Some no code engines can be very good for example the games hollow knight and hearthstone both created using a no code engine - but the unity ecosystem allows you to drop back into c# and integrate back into the engine so you're not limited by any defiencies...

[jglathe]

Solutions on an excel worksheet

Yeah that's the real world, ofc. Those users talk some sense, and nobody is listening to them, naturally. Well designed frameworks can help a developer (and maybe the advanced, technically interested user) a great deal, Low Code /No Code usually gets in the way. All. The. Time.

[Bbuckley]

We already have low-code. It's called "Python".

[Anonymous Coward]

Oh, for god sake, stop hiding behind "innovative software solutions".

Your problem is almost inevitably going to have it's real roots in a lack of traditional database systems analysis, normalisation, and referential integrity across systems.

If your data is well normalised and cross referenced, cross system, then you can use any tool you like downstream to chop up and analyse/update accordingly without breaking stuff.

"Low code" or other gimmicks like Business Objects making similar claims never address the elephant in the room that is proper system design.

[Chris Dockree]

Okay chaps ... for the last 10 years my business has run with a No Code platform. We have replaced ALL of the bespoke coded systems we had developed / managed / supported for our clients. We haven't come across a lack of functionality in what we use. And we run many different client services, customised to our clients individual requirements - such as maintenance services, Task Management, Large dataset extraction and submission, Project Management, government KPI services, educational services, Site Visit management ... and not a single coder involved on any of them.

Okay - we're a tiny entity in the grand scheme of things. But if you are interested in actual No Code experience, we certainly have it. And it IS the future.

[TechYogJosh]

Commentators here do not matter

Irrespective whether developers or others, including people commenting here like it or not, low-code is a big and growing market. Which means people are buying it. We can always crib that they are doing wrong, but this crib has happened before, multiple times like in cloud adoption, ERP adoption, dot com adoption etc. So cribbers crib and people who want to drive change (whether good or bad, based on how we see) change the world, earn lot of money, and move to next problems. People like us who comment on article like these just vent our frustration. What if any one of the people commenting here get a job at some low code vendor at good money (because they can afford) will they decline? Most likely, not. Net of it, get in line and help to assess how these things can be made better and be more useful than just summarily rejecting it. Cynicism is good only to a point.

[Tom100]

Low-code was never meant to replace developers, maybe no code with their citizen developers' aspirations.

When building a complex application that requires multiple integrations, low-code can be the solution if built right, with the relevant use case in mind. It is then used as a tool for the developer to shorten processes and focus on design. In a way like Excel changed the focus of the work with it, similarly the development processes and languages have evolve and require less one and zero programming. Low-code is just another stage in this evolution.

When it comes to SAP integration, there are not many tools out there, Mendix and Outsystems claim to have a solution for everything with some limited SAP knowledge, Pillir doesn't have that wide coverage but have an excellent solution built for SAP developers and application delivery teams. Appgyver while looks good, is really more of a no-code solution limited to the SAP walled garden.

We evaluated this different solution and chose one, which has been working extremely well for our supply-chain business applications, or dev team actually likes it and doesn't feel it replaces them or diminish the need of developers in any way