The low-no-code series – argodesign: Don’t (completely) kill off code editors
The Computer Weekly Developer Network gets high-brow on low-code and no-code (LC/NC) technologies in an analysis series designed to uncover some of the nuances and particularities of this approach to software application development.
Looking at the core mechanics of the applications, suites, platforms and services in this space, we seek to understand not just how apps are being built this way, but also… what shape, form, function and status these apps exist as… and what the implications are for enterprise software built this way, once it exists in live production environments.
This piece is written by Guus Baggermans is his capacity as design lead at argodesign – a product design consultancy that styles itself as a growth partner to entrepreneurs and an ‘incubator of new experiences’.
Baggermans’ original title for his piece is ‘Low-code is here to make devs more effective, not replace the code editors they love’ and he writes as follows…
In an enterprise environment, the justification for low-code platforms is simple: they serve to lower the barrier to entry, as well as return time to developers to focus on the hard problems. As a UX designer who’s worked on many such projects, this has always been my main goal and something I focus on imparting onwards to colleagues, clients and developers alike.
But why exactly should enterprises want low-code in the first place?
I’d argue that it’s for the same reason why we’ve accepted a lot of quality-of-life improvements in writing code for the past few decades: it makes us way more efficient.
Consider the simple idea of autocomplete features in code editors.
Common strings & things
As development projects progress, common patterns and actions emerge over time from team members. Code editors have evolved to detect these snippets from developers while they work, giving autocomplete options on things such as project variables or common strings, as well as having all developer documentation at your fingertips.
Baggermans: Gathering common actions & patterns makes a lot of good sense.
Github copilot is the next evolution of this, where it extends the code-editor pattern with the knowledge of millions of lines of code, based on best practices from the industry.
Quality-of-life improvements like autocomplete are pretty well-accepted by the industry… and for good reason – they’re great productivity boosters. In a similar way, low-code interfaces can make the task of development easier.
But low-code [although no-code more so] goes a step further and helps lower the barrier to entry for teams. They can help new team members understand parts of the system and allow people with less familiarity to onboard and become effective quickly.
As they grow more experienced, users can discover deeper layers of their toolset and progress towards going full-code.
Ability through humility
The way I treat low-code is as a trade-up, where common actions and patterns are gathered together to make them more discoverable while removing the manual labour involved with the more repetitive actions of coding. Rather than focusing on actions provided by traditional command line tools or scripts in a code editor, low-code sees the UI instead enable developers to be very productive in a subset of tasks that an interface is built around.
Implicit in this idea is that low-code platforms allow developers to peek behind the curtains and go full-code whenever needed. This requires a degree of humility on the part of UX designers and enterprises – there’s invariably going to be contexts where developers need to employ creative solutions and workarounds using traditional approaches.
Ultimately, a good low-code platform needs to accept that developers always want to be able to work with code directly.
Accepting this fact means that designers can craft a superior low-code experience and platform, while still allowing teams to quickly swap to the approach needed by developers when the need arises.