Low-code (and no-code) platforms are all the rage these days, with Gartner predicting that low code will account for 65% of application activity by 2024. As I’ve written before, a big part of this popularity is due to the promise that low-code tools allow an average business user (a.k.a. citizen developers) to create applications without needing to understand how to write a line of code. The result is an explosion in the quantity – albeit not necessarily the quality – of applications.
What is often overlooked is that low-code tools & platforms arguably offer even greater advantages for professional developers and IT departments. If you haven’t adopted low-code development already, here are four ways to make it pay off for you:
1Accelerate development cycles.
Even if you are a coding ninja, you should take advantage of any tool that helps speed up development work. That’s exactly what a good low-code platform in the hands of a professional will do, allowing the creation of more applications more quickly. By making existing teams more productive, low code can be one of the primary mitigation strategies for addressing the industry’s shortage of development talent.
Moreover, it’s not just that low-code allows developers to become more productive; it’s how it does so: it automates many of the more mundane tasks that developers loathe. Logic modeling, UI design, and even data schemas can be configured in far fewer steps than it would take to code them. Unless you’re still using manual SQL CREATE TABLE statements to prepare database entities, you already understand this; you’re likely using a design or management UI to configure those tables. This is that, but applied to, well, everything else.
There’s also a qualitative dimension to this; low code often means fewer mistakes. Simple syntax errors happen far less often, and a lot of exception handling, logging, and so on may well be built into the platform so individual application builders can focus on the application logic rather than dotting every “i” and crossing every “t.”
2Better align business and IT.
One of the challenges for many organizations is that IT tends to think and act in terms of practicalities and business stakeholders and users tend to think in terms of ideas. Part of every project involves trying to distill what business people mean when they ask for something, how much of it must work exactly the way they described it, which things could be negotiated into something existing technology is designed to do, etc.
Even when business requests are concrete and tangible, they reflect culture and work language that isn’t the same as what IT understands, so negotiation and interpretation are still very necessary, very time-consuming, and very frustrating.
If you think low-code is only for citizen developers, don’t forget that this problem will still exist, but in reverse; citizen developers rarely understand logging, auditing, versioning, staged deployment, change management, testing, security, etc.
I’m a strong advocate for a third approach, something called citizen–assisted development. The focus is on collaboration instead of abdication. IT and business work together rather than ceding all responsibility to one or the other party. Citizens own the design, but the design options have guard rails on them, making what’s requested automatically scoped to what’s actionable. Moreover, design prototyping is often done in collaboration with IT. IT owns construction and delivery. Everyone owns testing and continuous improvement.
This focus matters because only 10% of the work needed to deliver an application is dedicated to development. The rest involves all the work that happens before (requirements gathering, specifications, design, etc.) and after (debugging, integration, security, deployment, change management, documentation and more). Most low-code tools are focused solely on construction and ignore this reality, but exceptions do indeed exist.
3Leverage prototypes.
If it’s important to focus on collaboration between business and IT, we ought to be able to find a better way to achieve it than long and numerous envisioning and negotiation meetings, long specification documents, and so on. Enter the prototype.
Low-code prototyping requires a subtle shift in thinking: the goal is not for citizen developers to create applications out of whole cloth; it’s for developers to get these business users to show what they want rather than try to describe it. Once a workable prototype is in hand, developers can ask informed questions and begin to iterate on a solution. The prototype is the specification.
Moreover, these prototypes are designed using tools and methods that reflect what the available technology can produce. It can have a very real and positive impact on preventing developers from being bogged down in rabbit holes trying to hack together workarounds to accommodate an abstract wish for the UI that the platform isn’t really designed to provide. Prototyping tools guide everyone toward a common design language, which alone can help greatly.
4Embrace continuous improvement.
It’s a truism that perfection is the enemy of the good. In development, this often means that internal applications are only released after months (or years) of work once they’re deemed completely ready. This not only slows release cycles, but also means that applications are released into the wild with limited testing and feedback. Another truism: what people really want remains uncertain and abstract until they have something to see, evaluate, and criticize; people edit much more easily than they envision. Not having seen regular deliverables that they can critique and that get improved on a rapid series of iterations can be devastating.
If this sounds like an agile methodology, it probably should. It’s not a pure expression of agile development, but it borrows some principles from that school of thought and applies them to low-code.
Organizations should instead take advantage of low-code’s speed to quickly release initial versions with a plan to iterate. Does this interface capture all the necessary data elements? What are we missing for the overall workflow? These types of questions and answers become obvious when applications are in actual use. Moreover, people get fast solutions to their problems, and those solutions rapidly improve over time. Both serve to make developers the hero.
Low-code platforms are not a panacea. But in the proper hands – developer’s hands – they can simultaneously deliver more and better applications while making life easier for both business users and developers themselves. What’s not to like?
