Key Competences for Low-Code Developers

The result of Citizen Developers is a rapid increase in the quantity of applications – even if their quality often leaves much to be desired: according to a study conducted in the USA by the CIMI Corporation, 54 percent of Citizen Development projects fail within the first year of their runtime, and another 28 percent achieve only marginal results.

This is mainly due to the way Citizen Developers use low-code tools; loosely based on the motto: if you give someone a hammer, they don’t automatically become a carpenter. There is a significant difference between assembling an Ikea kit and making a custom cabinet. In other words, with low-code technologies, users don’t need to know how to programme, but they still need to think like a developer. After all, there’s a reason they’re called “citizen developers”. So what do low-code users need to know to successfully develop applications?

Modelling the process logic

Most low-code applications are created to automate or streamline activities that would otherwise have to be done manually. In doing so, they follow what is known as workflow logic: a certain state of affairs is followed by a firmly defined next step. Low-code developers must therefore be able to model this conditional logic – in their head, on paper or with the help of a graphics tool. They need to check the appropriate conditions before continuing the process, keeping in mind the logical outcome of the operation. What is interesting here is that trying to automate an activity is often the first time it has been formally recorded. Therefore, it is necessary to check what exactly the process entails and what requirements result from it.

Capturing requirements

When developers design an application, they first determine its requirements. This is to identify the company’s problems and determine what success should look like. In doing so, developers must also consider which other people are affected by the process – and how. For many, this sounds like a superfluous exercise, because the goals seem obvious. However, omitting requirements gathering can have far-reaching consequences: expanding the scope of the project, making adjustments after the fact, or feeling frustrated when a low-code application misses its target because of the lack of requirements gathering.

Handling exceptions

When modelling process logic and capturing requirements, the focus is usually on the flow of the process. However, there are inevitably exceptions to this, such as data entry of foreign addresses or process steps when key people are out-of-office.

People are able to handle these exceptions as a normal course of business – applications are not. Therefore, developers must anticipate and automate such exceptions. So they need to carefully check assumptions in advance and clarify where data or processes might fall outside fixed parameters. Then they determine what happens in these cases. And even if exceptions are handled manually, they should be able to be reconciled with normal activities at a later stage.

Modelling data

The process of data modelling includes not only modelling the process logic, but also structuring the data in a meaningful way. When developing a low-code application, this primarily involves the description of business units and their relationships – an extensive topic. Tools can take over many design decisions that would otherwise have to be made manually. However, some questions cannot be avoided: How does one deal with repetitive data? If companies and contacts want to be captured, does one cluster the contacts into a repeating group within each company? Or do you create separate tables for companies and people and add a mechanism to maintain their relationships using a table consisting of the person ID, company ID and job title?

Many low-code tools help reduce the need for users to delve deeply into the subject of data modelling and take care of issues such as entity normalisation and foreign keys. Nevertheless, they need to understand what these tools do and why – in order to be able to use data in the long term.

Consistent development of interfaces and applications

As low-code tools are used to develop applications, the number of applications and users also increases. Accordingly, these should be consistent and clearly structured (buttons in the same places, identical-looking data fields, etc.). The main issue here is practicability. If the design doesn’t have to be reconsidered every time, applications are easier to scale. And the more similar they look and function, the faster users will get used to them. Conversely, multiple ways of using different applications also mean many learning curves. Context switches between interfaces are exhausted.

Conclusion

As mentioned at the beginning, these are all things that developers need to know. This is not to say that low-code tools are useless in the hands of non-professionals – quite the opposite. The better staff understand how to think like developers when using these tools, the more successful they will be at developing good applications. And the better these applications are, the more they will be embraced throughout the organisation, which in turn will be better able to address greater business challenges and opportunities.

Philipp Erdkönig

is a consultant at WEBCON.