Five Things Low-Code Users Need to Know

How can citizen developers become better at their job? Find out.

November 3, 2022

Low-code (and no-code) tools are increasingly popular in organizations today. However, that has not ensured the best quality of output. Mike Fitzmaurice, VP of North America at WEBCON, shares five key capabilities and skills low-code developers need to improve to become better at their job.

Gartner predictsOpens a new window that the use of LC/NC tools will account for 65% of application activity by 2024. Low-code tools allow the creation of applications without needing to write a line of code. While this can speed up professional development, it’s better known for enabling people in non-technical roles to build applications, turning them into what is known as citizen developers. 

The result is rapid growth in the quantity – although perhaps not the quality – of applications.

One of the challenges lies in how citizen developers use these tools. The adage “to someone with a hammer, everything looks like a nail” is somewhat well known, but its corollary is at least as insightful: “giving someone a hammer does not automatically turn them into a carpenter.” There’s a big difference between assembling an Ikea kit and building a custom cabinet.

Five Keys to Building Better Applications

In other words, while low-code frees users from the need to know how to code like a developer, it does not free them of the need to think like one. There’s a reason they’re called citizen developers, after all. So, what things do low-code users need to know in order to build applications successfully?

1. Process logic modeling

Most low-code applications are created to automate or streamline activity that would otherwise be handled manually. As such, they follow what is known as workflow logic, or the cause-and-effect explanation of that process. In many cases, that’s represented by if this particular thing happens or is true, then that action or next step needs to take place.

For the low-code developer, this means that you need to be able to model – in your head, if not on paper or with a diagramming tool – this conditional logic. You need to understand prerequisite conditions, conditions that must be assessed or tested before the process continues, as well as the logical outcome that activity produces.

This brings up an interesting point: attempting to automate activity often represents the first time that activity is formally documented. As such, you need to think through what that entails.

2. Requirements gathering

Are you the only person this process touches? Who else is involved? Once this process is complete, what/who else might be affected by it? Will your attempt at automating this make a difference to them? When developers create an application for others, they go through requirements gathering, determining what a project must achieve and what is needed to make that happen. It involves identifying the business’s pain and building consensus on what success looks like.

This might sound like a needless exercise (you know what you need, right?), but consider what can happen if you skip requirements gathering: scope creep as a project balloons out of control, rework when you realize you overlooked a crucial step and a sense of frustration when a low-code application misses the mark due to lack of requirements gathering.

See More: Five Myths that Need to be Busted about Low-code Platforms

3. Exception handling

When people model process logic and gather requirements, the typical focus is what the process is supposed to be like. But there are bound to be exceptions, and that’s when things can get convoluted. This could come in data entry (like a non-U.S. address), a process step (an approver is out sick), or any number of other issues.

While people might be able to adapt to handle exceptions as a normal course of business, applications can’t. You either need to anticipate and automate the edge cases. This means you need to carefully examine your assumptions up front, identify where data or process might fall outside those parameters, and work through what happens in those instances. Even if you opt to add a means to allow unusual conditions to be handled manually, you’ll still need to provide a means to reconcile them with normal activity at a later time.

4. Data modeling

In addition to modeling process logic, you need to be able to structure data in a useful way. This is the process of data modeling. For our purposes in creating a low-code application, we’re concerned with how data describes business entities and relationships. It’s a big topic, and some tools are good at hiding a lot of otherwise-manual design choices, but some things can’t be escaped even if every effort is being made to keep things seemingly simple.

For one thing, how do you handle repeating data? If you have companies and contacts to track, do you make contacts a repeating group underneath each company, or do you maintain separate tables of companies and people and establish a mechanism to maintain relationships between them (for example, a table consisting of person ID, company ID, and job title)?

We can set aside talk of entity normalization and foreign keys, but this kind of stuff can’t be avoided. And doing it wrong has consequences. While many low-code tools will help alleviate the need to dive deep into data modeling, you still need to understand why they’re doing what they do if your data is going to be useable for the long term.

5. Interface and application consistency

When using low-code tools to build applications, success means more applications and more users. And that creates a need for consistency, clarity, and predictability. If you’re building five apps, they shouldn’t be five unique flowers, they should all look and operate in a similar way. Buttons should be in the same place, data fields should look alike, etc.

This is all about practicality. You can build more applications if you don’t have to stop and rethink their design every time. The more they look and act alike, the faster users can come up to speed. Conversely, multiple ways of using multiple applications means multiple learning curves and the exhaustion of context-switching between each interface.

The Able Citizen Developer

As mentioned at the start, if all these sound like things developers need to know, that’s because they are. That’s by no means to say that low-code tools lack merit in the hands of non-professionals – in fact, the exact opposite. 

The better employees understand how to think like a developer when using these tools, the more successful they’ll be in building great apps. And the better those apps, the more traction they’ll find throughout an organization, and the better they’ll address larger business challenges and opportunities. 

What skills are you looking for in a low-code developer? Are efficient resources easy to find? Tell us on FacebookOpens a new window , TwitterOpens a new window , and LinkedInOpens a new window .

MORE ON LOW-CODE: 

Image Source: Shutterstock

Mike Fitzmaurice
Mike Fitzmaurice

Chief Evangelist and VP of North America, WEBCON

Mike Fitzmaurice, WEBCON’s Chief Evangelist and VP - North America, has more than 25 years of product, consulting, evangelism, engineering, and IT management expertise in workflow/business process automation, citizen development, and low-code/no-code solution platforms & strategies. His decade at Microsoft included birthing technical product management and developer evangelism for SharePoint products and technologies.
Take me to Community
Do you still have questions? Head over to the Spiceworks Community to find answers.