Can we move forward without waiting in the queue?

Low/no code, enter the room.

In this blog, we investigate whether in the future, everyone out there (including us) will be building applications themselves, on low/no code platforms.

It would certainly appear that way, if you believe everything that is posted on Linked-In, Medium and IT trend watcher blogs. With an unlimited assortment of Lego blocks of prefab code, the sky's the limit. No need to ‘turn it off and on again’, raise a ticket or wait in the queue. Maybe.

Hypergrowth

Low/No code platform growth is predicted to be huge over the next decade. To the point that some sources say there will be > 10x growth and that 65% percent of all applications will be developed on these platforms, in house.

The application development would be assisted by robots too. This is a massive change to where things stand today. Even if we only make half of this transition, it would be impressive in terms of the rate of change.

In line with our blog last week, low/no code isn't a new phenomenon. Interestingly enough, the low-code no-code movement originated in the 1970s, or possibly even earlier.

We see a pattern here :) - the old is the new. The now considered ancient COBOL-language has been associated with the earliest stages of the low/no code revolution, due to it being considered a high-level programming language. This simply means it involves a level of abstraction to what was available before.

If we think through what low/no code is today, an even higher level of abstraction is certainly one of the key elements.

The term ‘Citizen developers’ is another key ingredient. They can be anyone in an organisation, and build functional but limited applications without writing a single line of code. It is also said they should be called ‘assemblers’ rather than ‘developers’ , since they focus on arranging (these Lego) blocks of code rather than writing it. They build applications for customers, and/or applications that are internal to the organisation.

Why now?

The acceleration in low/no code update is mostly driven by the increasing pressure on IT, via a perfect storm. Internal and external customers have higher expectations in terms of value/ excellence, and the COVID-19 pandemic and lockdowns have added a whole new dimension of security considerations and increased bandwidth requirements. The IT team is truly between a rock and a hard place.

Some of the benefits low/no code is delivering already, is workflow automation, legacy technology modernisation and deploying applications on multiple platforms. More importantly to us, they use and leverage lots of APIs, which of course is music to our ears.

However, as always, low/no code doesn’t mean “low or no risk.” There are some draw-backs to using these platforms.

Customisation will be more limited than in more traditional software development projects, and this might impact the user experience and how refined it can be. In addition, a platform isn't always a platform, isn't always a platform, if you know what we mean. This means, take finding the right fit for your organisation seriously.

Finally, and again most importantly to us, the out-of-the-box integrations that the out-of-the-box low/no code platforms provide, will have limitations. So once again, we are happy to fill the gaps - which is definitely another pattern we are discovering for our own use cases.

Hyperautomation?

If you ask software developers, some more fundamental risks are also worth mentioning. Fragmentalisation of an organisation’s IT landscape and increasing data silos, possible security issues due to ‘Citizen assemblers’ not having sufficient IT background to understand these broader risks, and - possibly - integration problems, if APIs aren’t set up appropriately. The low/no code development is the opposite of the hyperautomation trend in these aspects.

“It’s too early to tell whether citizen developers will act as “cowboys,” satisfying just their own selfish information needs potentially at the expense of others or whether they will consider the big picture. We’ll know in the next few years.”

We understand that software developers are of the opinion that time is money, and you get what you pay for. “They need to handle the glitches, fiddle with undocumented features, and figure out how to satisfy the requests to do things just a bit differently.”

Therefore, the software development community has been somewhat critical of the low/no code development as a panacea for all.

To them, it means having to do re-work down the track, once the low/no code application runs out of steam on version control, testing/debugging, the ‘Citizen assembler’ leaves the organisation (we have all seen the orphaned Excel Macro and Access Database application drama movie before), creating ‘technical debt’ (i.e. future tech expenses for quick/cheap solutions today).

What we make of it - the use case

As with anything, the use case is King. Is the application intended to be built, suited to a low/no code approach, meaning there is a very low chance of it requiring customisation in a few months/years time? Or is this a proof of concept, minimum viable product, or similar experimental stage project where it is crucial to quickly showcase functionality and budgets/skills for coding are lacking?

These two scenarios are quite clearly favourable to a low/no code approach.

In a scenario where you will likely need customisation, due to industry specific or future regulatory requirements for example, a low/no code approach is not without risk and can be more costly than custom development, judging by the experience of others online and developers in our IT network.

Naturally, there are many scenarios between these two extremes.

And, we need to bear in mind that low/no code is subject to ongoing development - like any trend, it is ever changing. After all, we’ve been at it since last century. In addition, it fits into the broader realm of software development automation, and no-one knows yet how far that might go.

In conclusion

After writing this trend review blog, what we have learned is that integration technology is a necessary force for making good things happen more smoothly, no matter if there is (high) code, low-code, or no-code.

So, will we all be building our own applications in the future? To a degree we suspect we will. However if we do, we will always be limited to the available Lego blocks (unless we include ‘high’ coders in the team, platform allowing). It will certainly work hand-in-glove with integrations to unburden IT teams and empower ‘the people’ to satisfy their IT needs.

Picture by sttimm on Pixabay