Low-code development's popularity has been steadily increasing for years now, with no signs of slowing down. Its appeal is that it gives users the ability to create software applications through a graphical interface, with little or no need for programming in the traditional sense.
But low code is not without a significant downside if it's adopted without a long-term strategy in place.
By abstracting away the need for code, low-code tools and platforms offer a faster development process—and a more inclusive one, too. Business users, sometimes also acting as citizen developers, can create applications on their own, without waiting and without having to explain their requirements to someone else. With more people able to build applications and with the development process taking less time, simple arithmetic suggests that low code should have a significant effect on application backlogs.
But, and I cannot stress this enough, low code is great for professional developers, too. Armed with good low-code tools, developers can become considerably more productive, producing more applications more quickly and with fewer people. Gartner predicts that low code will make up 65% of application activity by 2024, but I suspect it'll reach that point even sooner.
Moreover, there's a qualitative dimension to this; a lot of the speed comes from having the platform take over mundane (but necessary) chores normally left to coders.
According to the Project Management Institute, low code addresses what 86% of IT decision-makers say is the biggest digital transformation challenge: too few software developers. Citizen and professional developers alike are eagerly diving into low-code projects. But most low-code efforts, especially those spearheaded by citizen developers, are one-off tactical projects with a very narrow focus, and this can lead to risk.
It's why organizations need a strategy for long-term success. Without such a strategy, organizations end up with a host of orphaned apps and broken workflows. Long-term planning for low code requires thinking about things like durability, reusability, scalability, and agility.
Durability
Making low code work for the long term means building applications that will last. This is true for any development effort, but low code can tempt people into ignoring that and just throwing something together. Often, when citizen developers use low-code tools, they focus solely on scratching a specific itch. Even professional developers tend to regard low-code work as something for an MVP, or Minimum Viable Product.
What they either never knew or rarely keep in mind is that, by a conservative estimate, only 10% of the work needed to deliver an application is spent on development.
There are countless other critical aspects when it comes to delivering an application: requirements gathering, negotiation, tool selection, design, specifications, debugging, metrics, profiling, auditing, security, maintenance, change management, deployment, documentation, user education, IT education, and a lot more.
Applications die quickly if those issues aren't addressed. The delivery cycle matters at least as much as the development cycle—but very few low-code tools and platforms pay attention to anything beyond the construction of an application.
Creators quickly learn that once their application's user base grows beyond themselves, those users have priorities of their own, which can conflict with earlier design decisions. Prioritization becomes important. Plus, there's support and training. Low-code creators may not have to think like a coder, but they won’t be able to escape having to think like a deliverer.
At this point, citizen developers have three choices: (1) treat quick-and-dirty applications as disposable and move on, (2) hand the application over to IT, or (3) start to think like a developer even if they aren't going to code like one, paying attention to design patterns, normalization, reuse, etc.
Now imagine having dozens, or even hundreds, of such applications throughout your organization.
Reusability
This certainly means reusing applications, data, and other assets—that's well-traveled territory. But it also means reusing knowledge and skills, and those aspects are not often discussed.
Reusing patterns, practices, and platforms reduces analysis paralysis. Life is much easier for IT, auditors, and users if they don't have to reinvent the wheel every time a new application emerges. This means they don't have to assess, acquire, and adopt individual infrastructures to bring each new application to life. Relying on reusable tools and rules matters for businesses to be able to deliver multiple, consistent applications that follow common practices.
A large part of reusability also comes down to consistency. Developers and end users alike get more done when applications have a consistent look, feel, and behavior. There's less to learn for each new application. App creators don't need to engage in context-switching. And when someone gets promoted, leaves the company, or just goes on vacation, consistency increases the chance of someone else being able to take care of their applications.
Again, we're talking about scaling sets of solutions; there will always be room for a few special projects that are truly unique, but they're not the norm. It's good to locate form buttons in the same place for every application, to use consistent field names, etc.
It's admittedly not exciting, but it is a lot more productive once you look past one application at a time and consider the total throughput of an organization. Exciting UI can be saved for a public-facing website, while everything else can focus on high productivity and low ambiguity.
A good way to tell if an application is intuitive and consistent is whether someone who didn't build it can nevertheless use it quickly, without any training. You won't achieve that if every quick-and-dirty application is treated like a unique work of creativity.
Scalability
Being able to effectively scale low code is also key to long-term success. Many organizations that are committed to low code still focus on one application at a time. They may even revisit a variety of different tools/platforms for each individual project. This can easily lead to a good-for-me/bad-for-us situation, and it limits the ability for low code to have a positive overall impact.
Organizations that do everything on paper, spreadsheets, and email are indeed taking a consistent approach, just a slow and inefficient one that doesn't allow for reusability. If the digitalization of a variety of processes creates cacophony, the organization itself can't scale. Application development certainly can't, either. A reusable environment is a scalable environment.
If you focus on consistency and reusability, you don't have to build everything at once. Pieces of applications can emerge over time and have a truly cumulative effect. Individual activities in an overall business process can be built over time if you understand the process and can rely on the tools/techniques/training. The right planning still allows for lots of quick wins, just not chaotic quick wins.
Agility
The long haul also means continuous improvement. Many organizations treat low code the same way they do traditional codebase efforts; namely, they focus on creating a totally perfect application the first time. That's a problem; the whole point of low code is to improve productivity, but if analysis takes just as long and the only thing that's sped up is construction, the gains are minimal.
In fact, the entire DevOps movement is a response to that kind of thinking. It focuses on short development cycles, incremental releases, and continuous improvement. The world of low code should have similar priorities.
If consistent tools and techniques are in place, it's very possible to release less-than-perfect solutions quickly and enter a continuous cycle of feedback and responsiveness. The method of doing so will look different from what DevOps practitioners use, but the principle is identical. But again, this won't work without thinking beyond one application at a time.
What's more, releasing early and improving frequently results in better work. Most people find editing easier than creating. Some business stakeholders aren't especially good at imagining and describing what they want, and some developers aren't especially good at understanding business requirements. Rather than negotiating abstract ideas in advance, collaboration is the order of the day.
Imagine a police sketch artist working with a witness; it's collaborative. The artist draws a little, asks the witness to correct the work, and adjusts it. What definitely doesn't happen is demanding that the witness describe someone's face in exacting detail before the artist begins to draw.
Moreover, even when what was requested is indeed what was delivered, extra requirements come to light or circumstances change. Rapid response to feedback and continuous improvement are necessary after application delivery.
Making low code go the distance
You have a choice to make: curation or chaos. It ought to be a conscious choice. The key to long-term success is twofold: thinking holistically, and choosing one's tools and techniques carefully. Not every tool or platform is change-friendly. Not every product focuses on things other than constructing applications (they ignore that extra 90% of delivery).
Letting low code happen isn't conscious, but making it happen is. Only CIOs and IT departments can make this long-term strategic approach happen. It won't occur organically. It's a struggle, but one worth winning.
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
