Traditional software engineering is still better than 'low code'

I’ve worked with several ’low code’ platforms in recent years. Some are better than others, but I’m always asking one question: What problems are they supposed to solve?

The biggest of them is ’technical debt’. Dependencies become outdated and unmaintained, updates sometimes have breaking changes that require code to be reworked, additional code gets tacked on over the years by various people, amateur code makes that harder, etc. Technical debt might be an inevitability for an organisation that’s been developing software in-house for long enough.

Another one is security compliance. A couple of years ago, we experimented with MEND, which reports dependencies with known security vulnerabilities, comparing the manifest/package files against a CVE database. Seemed like a good idea at first, but it was quickly obvious that security researchers, eager to score Brownie points, were running scanners against random packages, and submitting arbitrary and unvetted CVE scores. The scores are worthless by definition, because the severity and exploitability are determined by where the dependencies are used. The ‘vulnerability’ might not even be exploitable in a given application.

If one recognises that the number of outdated dependencies - the potential attack surface - is way more important than the scores themselves, MEND can still be useful.

The compliance people, though, didn’t see it that way. MEND is marketed as a vulnerability reporting system, and if it reports a critical vulnerability, the software officially has a critical vulnerability, and it needs patching (or at least mitigation) within a given timeframe. The thing is, in order to do that, we’d need to assign several developers to constantly monitor vulnerability reports, update dependencies, fix whatever breaking changes that might cause, test the software and submit RFCs. And there could be more vulnerability reports for the same application the following week.

Migrating services to Microsoft Azure, as Logic Apps, is a partial solution to all this. Microsoft would take on the responsibilities and workload of keeping everything patched, on a continually updated framework, running on a managed service that’s already compliant with whatever security standards.

The following are the main things I don’t like about ’low code’, though.

Traditionally-developed software is generally more efficient

I use the word ‘generally’, because the comparison is going to vary by programming language and framework. A .NET DLL, running on whatever server, is blindly fast and extremely efficient, even if the code is crap, thanks to decades of optimisation and memory management behind the framework. Visual Studio’s scaffolding encourages us to make use of that.

The components we find on a ’low code’ platform, on the other hand, are considerably less efficient, because they’re generic abstractions that aren’t engineered for any specific use case. I suspect there’s be a lot of duplication happening in memory during runtime, with multiple objects that do pretty much the same thing being instantiated at the same time. Most services will also run on a VM of sorts, which would typically have far more limited resources. Scaling up an integration can be very expensive if the resources are maxed out.

Code is much easier to debug than ’low code’

With traditional coding, nearly every problem can be narrowed down to something very specific. I can turn a JSON array (or XML) into a strongly-typed list, with definite object types, implement whatever complex logic, and convert that list to a different JSON array. That’s a transform, and it can be done very specifically. A specific object in a large amount of data can be traced though each line of code.

Most of that can’t easily be done on a ’low code’ platform. At best, we can set breakpoints at the steps where we think a bug is, and then guess which part of that step is causing the issue. That step could be a Function App with several hundred lines of code, or it could be a complex DataWeave transform. Debugging that often entails guesswork.

One platform I sometimes use literally has no debugging features whatsoever, or anything to indicate the reason a validation error message might be displayed. We can only add and delete steps, and guess where the problem might be.

There’s not much documentation

We’re used to finding code on Stack Overflow that’s an approximate solution to a given problem, and copying and reworking it as needed. Even experienced engineers frequently do this.

Because they’re not as commonly used as core programming languages and frameworks, documentation for ’low code’ platforms can vary from crap to non-existent. We certainly can’t find answers to defined problems with them on Stack Overflow, the way we might with C# or Python. A couple of vendors I’ve encountered didn’t bother too much with documentation, and are instead reliant on users posting and answering each others’ questions for that.

What to do? I detest the idea of using ChatGPT to produce code and solve problems for me.

A low code service might involve a lot of non-engineered code

Because ’low code’ services are built from generic components, most the ones I’d deveoped incorporate hundreds of lines of custom C# and DataWeave. That amount of code should follow SRP and span multiple classes. That could only be done by compiling the re-usable classes and loading them as dependencies, but the chances are I’d want to repurpoe the code for something else.

That being said, I have seen impressively well-engineered Mulesoft applications that do follow SRP, with the generic re-usable stuff moved to other layers. The thing is it becomes much harder to figure out what a flow does beyond three layers of that.

Low code development skills can be less transferrable

Perhaps every engineer tasked with ’low code’ development is secretly asking themselves whether it’s a career killer, and whether the skills and experience - which will be heavily vendor-specific - are transferrable.

I don’t think it’s much of an issue with Azure Logic App development, since a Logic App developer is likely to know a lot about Azure in general - Logic Apps, Function Apps, Key Vaults, Resource Groups, App Registrations, Storage Accounts, a bit of Active Directory, etc. There’s a lot of crossover between that and DevOps.

Mulesoft, is a double-edged sword, I think. Organisations know they’d be paying a premium for developers with Mulesoft expertise, and for a platform that’s a lot more expensive and problematic.