Low code evolves and outmaneuvers “high code”

Hey,

My name is @jesper. I work in the IT services industry, as Senior Test manager primarily for the enterprise and public sectors. My specialties are RPA, SME-based testing and test strategies.

I have been following the works of Simon since 2012 incl. the original blogposts. I have recently started mapping test strategies, and see a huge potential and I’m experimenting, as it is novel.

Recently I have created this map:

lowcodewardley919×608 41.5 KB

It shows that: Low code automation tools (RPA) builds on responsive web apps to deliver more user visible services. The current stage is emerging. Also it competes with “high code”.

If I had run business in this field, I would do focus innovation on low code/no code tools for fast customer visible automation efforts.

I would like to discuss this map.

Best regards,
@jesper

Hi @jesper,

thanks for this article. Have you had a chance to think about future effects of low code and whether there is a chance that Jevons will kick in and support creating tons of difficult to maintain solutions?

Your map shows a single “Business Need”. I think there are different types of business needs, some of which can easily be met by low code systems, where others (currently) can only be met by “high” code systems.

The software development industry has a long and troubled history proclaiming the end of programming as we know it. Call me skeptical.

I agree. Low code will always be domain specific. Domain specific languages will be increasingly useful, but third-generation programming languages (3GL) provide the requisite variety to design and implement novel solutions.

Hi Chris,

Well spotted! Jevons Paradox kicks in indeed!

These drivers probably to make the barrier to entry seem more manageable. The visual ones very easily turn into visual spaghetti code if you don’t keep an eye on it and use sub flows, low coupling and high cohesion [13]. … as with any other non-trivial code (of a certain McCabe complexity [14]). One interesting way to go about a “coding” practice for visual test cases could be inspired by how BDD can be implemented in LeapWork [8] with annotation and self-referencing unit tests.

At the end of the day even a visual test automation project is a coding project, that should be part of the project code base like everything else [3]. And probably best maintained by software engineers within the project team (where possible) – unless you want a team of test engineers spending all day playing catch-up to maintain the automation code.

hi @rsinnema1
Appreciated!

As I wrote in the blogpost: Perhaps RPA tools and similar Low-Code tools can be compared to the macros of If This Then That , where you can automate tedious repetitive tasks – also among your business tools.

Low-Code and RPA specifically can be mockingly seen as “poor man’s integration”. Ie that business would rather build RPA between systems than “real” integrations. There’s a great piece about it on Horses for sources: RPA is dead. Long live Integrated Automation Platforms - Horses for Sources | No Boundaries

My map is simple, I know, but the key is that Low-code tools are emerging and taps more into a (visible) business needs than existing solutions.

oh indeed - and solving the halting problem too. It’s just a higher order level of programming. … where are we now 7th generation?

Btw: the same map applies to home automation/smart houses, albeit with even more evolved tools.

Thank you John.

It could very well be that low code is primarily domain specific ie: RPA, IFFT, smart homes.

Here’s a piece that talks more about low code as the next wave of software…