The rise of Low Code Application Platforms and Software Developers

In the last few years, any self-respecting "Top N Trends In IT This Year" article must include a variant of the "no-code"/"low code" category, pointing to a significant transformation of future software development.

And this future is now.

In 2020 Gartner had published a "Magic Quadrant for Enterprise Low-Code Application Platforms," stating that "[d]eveloper shortages and skill-set challenges are impacting … ability to deliver increasing levels of business automation in a rapid and reliable fashion."

The proposed solution to the problem is adopting LCAPs (low-code application platforms) that require "smaller and less specialized teams of developers."

Gartner had predicted that "[by] 2023, over 50% of medium to large enterprises will have adopted an LCAP as one of their strategic application platforms.". In addition, Forrester suggested that by the end of 2021, 75% of new application development will use low-code platforms.

I am not sold on a 75% percentage number. It seems somewhat large and too roundly perfect.

Regardless, the change is coming. Why now? And will computers finally take our jobs?

We all felt "developer shortages and skill-set challenges." Projects and deadlines are flying at an accelerated pace, and the skills you've mastered today may no longer apply in just a few years.

AI, Digital Transformation, Automation, Cloud Computing, E-Commerce - these are no longer early adopter trends or fancy buzzwords to put on PowerPoint presentations. Instead, it's a requirement for businesses to survive and grow.

The demand for implementation services puts additional pressure on software developers to level up their skills while still delivering product changes for existing legacy projects. And constantly tightening deadlines do not make it easy.

The pandemic of 2020 had greatly accelerated this cycle. If "going digital" and "cloud migration" was on the roadmap before, these goals quickly solidified and jumped to the front of the line because business survival depended on fast and efficient implementation. "Adapt or die" meant taking the opportunity of new markets, which also placed a high demand on new development.

The year was very hectic for most of us who writes code or provides IT services.

And the desire to replace the developers - for end-users or other developers - is not new. WordPress and Wix had long provided non-technical users with the tools necessary to create their websites or web applications. You would need an excellent reason to have a homegrown support ticket system instead of Jira since the team can use custom fields and automated flow management to satisfy most scenarios. And integrating with Okta/Auth0 provides a secure, customizable, and scalable solution fast, with just a few lines of integration code.

Should developers adopt LCAP as another tool?

What is LCAP?

Low Code Application Platform is a visual development tool that makes it possible to create and deploy applications and components with just a bit of scripting - or no code at all. Prebuild templates and processors can be customized, extended, and snapped together to form a fully automated flow.

But LCAPs are much more than just the box of Legos. It may support enterprise-grade functionality, like disaster recovery, scalability, security, data access via APIs, and multi-language support. In addition, trainable AI models and automation for data routing and event hooks allow for more sophisticated flows. And the ability to extend the components with code provides the ultimate rapid development flexibility.

The robots took our jobs!

Relatively high subscription costs for LCAPs still pale in comparison with the average software developer compensation.

Collectively we've automated a lot of people out of their jobs. So I suppose it is a fair question - will software developers become obsolete while business users drag and drop components on the canvas? Will software development be reduced to writing few lines of the script here and there by citizen developers?

It's hard not to remember the Fifth Generation Computing project, spearheaded by the Japanese Government. The project was intended to create a new type of computer and a knowledge-based program creation - where the user could ask the machine directly to solve the problem via a human-like interface instead of asking a developer to write a program to solve the problem.

The project took ten years and had tremendous success in training an entire generation of highly skilled software engineers.

In the end, it did not create a knowledge-based computer. However, some 30 years later, the problems that the project meant to solve are still applicable.

Any domain-specific software system requires a software engineer that is also a domain expert. Not only fluent in Software Engineering Body of Knowledge but has a deep understanding of the domain, its applications, language, and users.

This knowledge acquisition remains, in my opinion, one of the reasons why software projects fail or take so long to be developed. The project can hit all essential metrics and contain beautifully designed and executed code. And then be rejected by the users because the requirement gathering had failed and the software did not reflect how they work, the language they speak, or the information they need.

LCAP has the potential to give power to the domain knowledge expert.

Use resources wisely

LCAP could be the next logical step in commoditizing software development, and it's a good thing.

Develop few production-level apps, and everything starts looking easy. "Can we put up a new form to collect data on the website?"

No problem.

"We need to have this new data collection pipeline running."

Give me 2 hours.

"Is it possible to build a chatbot that asks a visitor a few questions before directing them to the right support group?"

You bet!

These tasks are not particularly complex, but they take time, especially when done correctly. So is it the best use of a scarce and therefore valuable resource? LCAP can alleviate developer's load by reducing the time required to perform ordinary tasks, allowing them to concentrate on creating genuinely innovative solutions for complex problems.

Sure, you can write a chatbot. And then modify a chatbot, deploy it, integrate with the back end, post more tweaks and edits, and then deploy it again.

Alternatively, you could ask your users to drag a chatbot template on the canvas, edit the flow to suit their needs, test it and let you know when they are done.

Then, include a small piece of embeddable code on the page - and spend the time saved working on something truly remarkable.

Shadow Developers

Another potentially significant benefit of LCAP co-existence with traditional development is bringing the super users out of hiding.

When schedules are tight, internal projects usually take the back seat. When developers are too busy, users improvise and craft automation using the tools at their disposal. They may use a complex Excel spreadsheet full of formulas or a script written in Python - a tiny pebble, sure - but the one that may prop an entire department, and you have no idea it exists. Until one day, when the new patch is rolled out to the system, crashing the pebble of shadow automation and suddenly panic ensues.

Or worse, the automation annihilates your carefully crafted authorization scheme, exposing restricted data to anybody who stumbles across it.

Having such empowered super users on your side, actively creating applications in the open, is a win that can lead to more innovation and great ideas.

LCAP Pitfalls

I've seen similar concepts rise and fall in the past - fall, mostly, because nobody wanted to build things from scratch as it looked too daunting and complicated. The current approach of providing templates and prebuild apps is much better in terms of creating user acceptance.

LCAP can help in creating rapid prototypes and proofs of concept.

But in the end, citizen developers and power users are not trained software engineers, and we still need to be the guardians of security, maintainability, and performance. We still need to make sure the data entering the system is valid and data leaving the system is doing so for a good reason. We need to design our data structures and code defensively and provide guidance and education.

We should also be voices of reason when it comes to critical business functionality. Companies fail, close, get bought out, or decide to raise their subscription costs to the Enterprise level. A code written in Python will always work, while a flow created via LCAP will stop functioning when your subscription expires, or the company closes its doors.

Software developers will not disappear, but the industry will change. LCAP is not a competitor but a great tool to add to your toolkit.