The “problem” with low-code (and how to fix it)
In technology, perceptions change. Usually (but not exclusively) as a result of a major new platform, device form factor, or change in a major industry-wide protocol or process, we, humans, form our ideas about technology by directly consuming it as we see it evolve.
In 2010, few people outside of the hard-core programming community actually used the term “application”, meaning “software application”, as it obviously does. The birth of the iPad in 2011 and the subsequent smartphone world of course changed that level of perception, so everyone and their grandmothers now use the term.
Go back maybe half a decade and the same goes for low-code & no-code (LC/NC) software tools. Although not yet necessarily familiar to the consumer masses, it is a term that most business people are familiar with today, even if they do not work in the IT function itself.
But as with all technology, there is always a cycle of hype, so should we take a step back and take a more considered view at this point? Given that many platforms and tools in the low-code and especially no-code space are marketed as so-called citizen users (even citizen developers), how safe is it for us to start to push even more of these features?
Development is not just building
Some say these new toolsets represent too narrow a focus on building. Ask anyone with a professional software engineering certification about real-world deployment and they’ll tell you that developing application code is only a fraction of the story. There is requirements gathering, design, modeling, security, deployment, release management, change management, metrics, monitoring, auditing, compliance, maintenance procedures, user adoption and engagement, feedback collection and much more.
That’s the firm opinion of Webcon’s Vice President for North America and Chief Evangelist Mike Fitzmaurice. Webcon is developing a low code Business process automation (BPA) platform that enables the delivery and continuous improvement of enterprise-grade business applications.
“It’s also not clear if someone who gravitates toward low code/no code wants to care about anything beyond building a simple app that scratches a personal itch,” he said. worries Fitzmaurice, who insists that he would (mostly at least) prefer to see LC/NC tools placed in the hands of professional developers, who really know how to use these tools.
The Webcon team are used to dealing with this kind of technology and say it’s the pros who realize there’s more to delivery than building, who can focus on the big picture…and who can take advantage of templates design patterns (and actually know what design patterns are in the first place).
But there is room, admits Fitzmaurice, for low-code to be embraced by citizens and professionals alike. He says it’s not impossible for a single platform to be flexible enough to meet the needs of both constituencies. We even have room to address a hybrid model, citizen-assisted development, in which citizens own the design, professionals own the development, and an amalgamated team of peers share responsibility for delivery.
“It all comes down to too little attention to collaboration and communication,” Fitzmaurice said. “The mental image many have of low-code development is that a person drags and drops something smart together in their spare time. They don’t need to figure out how to explain requirements or on-board users because ( at least initially) the customer, designer, developer, and user are all the same person. This may be accurate, especially in citizen developer scenarios, but it’s not universal – and it doesn’t definitely doesn’t fit.”
It’s true to say that any solution that reaches critical mass (meaning use beyond those building it) will need to be explained to other people. Since low-code projects tend to involve small teams (often just one person), they carry a greater risk of the developer being unavailable due to something as drastic as leaving the company. or something as common as a vacation.
Illustration, explanation, communication
“If it is citizen development, i.e. the developer does not create applications every day, it is even possible that months will pass between the periods devoted to an application — and in such cases, the challenge is for the developer to communicate proactively. with their forgetful future selves,” Fitzmaurice explained. “You have to focus on clarity. On illustration. Upon explanation. On communications. Ease of construction does not guarantee ease of understanding.
There are broader issues to consider here; In some ways, low-code projects can be harder to communicate than code, because a number of analytics and meta tools exist to compare, profile, describe, and explain what code does. That said, these value-added tools depend on using discipline and process to derive value from them.
But Fitzmaurice raises another issue; he suggests that in the low-code world there is too much emphasis on one application at a time. We’re not saying we need to sound the corporate alarm so we can watch out for anarchic one-off citizen-developed apps, but we’re saying there’s a potential risk of less consistency across low-code apps.
This is perhaps the easiest of the “problems” presented here to solve. Technology platforms that can deliver multiple consistent applications to a centralized common “place” (which can be a single data store, a single code repository, or a single cloud instance) and that follow common practices make everyone’s life easier . Luckily, low code already comes with tradeoffs (losing a bit of flexibility to gain a lot of productivity), so this shouldn’t meet too much resistance.
Inevitable… and also desirable too
When we take stock of this discussion and look at where we are in the app world, we have too many user requests being handled by too small a talent pool. For that reason alone, Fitzmaurice agrees that low-code and no-code are not only inevitable, but also desirable. But a lot depends on the quality of the tools and platforms selected, the methods used, and the organizational willingness to take the effort seriously.
“These are issues that professional code-based development has struggled with for what seems like forever. We in the low-code/no-code world have an obligation to learn from them and adapt their techniques to our new reality. In various corners of our industry, this work has already begun,” concluded Fitzmaurice.
It is not a question of whether we will solve these problems, but rather of how long it will take and what the result will be. Paradoxically perhaps, what we really need in low-code next is low-down.