The terms "low-code" and "no-code" are currently on everyone's lips: These words are bandied as a cure for the shortage of programmers or as a way of turning subject experts into software developers. On the other hand, some experts doubt whether you can really get high-quality software by just clicking around. Linux Magazine spoke to one of the low-code pioneers, Karsten Noack, about the meaning and purpose of low-code technology. Noack has been developing innovative methods and procedures for programming-free software since the early 1990s. In 1998 he launched SCOPELAND Version 1.0, which some consider the world's first low-code platform. Today he is the managing director of Scopeland Technology.

Noack is currently a member of the BITKOM main board and forum spokesman for SIBB, the Berlin-Brandenburg IT industry association. He also chairs the board of the Low-Code Association.

Linux Magazine: Why do we need low-code?

Karsten Noack: Low-code represents a fundamental paradigm shift in software development. The aim is to be able to develop customized software solutions in a far more efficient, cost-effective, and flexible way using completely different methods and tools. This approach enables companies and administrations to push forward with digitizing their business processes. On top of this, low-code is an answer to the shortage of skilled personnel because it helps existing software developers do more in the same amount of time, and it also helps to bring more people into the development process.

LM: Some consider low-code a semi-professional gimmick that is unlikely to work for serious problems. How far can it really take us? And when do you still need classic software development?

KN: Low-code has long been a reality, not only for small and simple use cases, but increasingly also for mission-critical core applications. Even for large projects of all kinds, low-code is becoming the preferred method.

LM: So is low-code the panacea, or are there limits to its use at the end of the day? And isn't the low-code platform itself indicative of the applicability limits; after all, it must have been developed without low-code at some point?

KN: Of course, low-code is not a panacea. The limitations lie in the individual low-code platforms, and they are usually tailored to a specific target market or class of tasks. Because no one can foresee all the potential challenges – there are always requirements that a particular platform cannot cover – the low-code strategy explicitly offers users the ability to add manually programmed scripts or macros in cases where you cannot handle the use case using the quick and easy configuration options. If you can simply click together 98 percent of the functionality you need, the two percent that you still need to program is virtually insignificant from a business point of view. The line between what low-code can and cannot do is blurred.

It is true that the low-code platforms are mostly programmed and not developed using low-code. But that is also obvious, because low-code is primarily used to create individual, company-specific IT solutions.

LM: Doesn't low-code promote shadow IT, where everyone's a programmer so the actual IT staff loses control of the environment? Or will we even need central IT departments if it catches on?

KN: It is a big misconception that low-code serves to promote shadow IT. Perhaps this is because low-code was, first and foremost, used for the development of non-critical small applications in specialist departments. This is why even today people occasionally refer to "citizen developers" in the context of low-code. Today, on the other hand, shadow IT for low-code hardly plays a role at all, and establishing highly efficient low-code methods instead of classic coding is a central issue in IT departments as a key digitalization technology.

It is true, however, that professional low-code developer teams are often located in the business units, or at least somehow set up as entities separate from the rest of the programming team. There is a simple reason for this: We are looking at a paradigm change, and separation is more conducive to developing new methods. In the long term, however, things will relax and grow back together.

LM: A user who becomes the programmer also inherits other programmer duties, such as support, on-going development, or security updates. Wouldn't they be in over their heads?

KN: It's not true that users become programmers and inherit all the duties of programmers. There are, and always have been, career changers from business departments who are increasingly drifting into IT, and low-code makes this easier than it ever was in the past. However, these people do not typically use the programs they develop or help to develop. Of course, it is true that users will be more involved in software development processes in the future, for example, through active participation in the design of program interfaces. But this does not normally make them programmers.

LM: To exaggerate, it sounds as if the typical low-code developer is neither the studied computer scientist nor the user most familiar with the business side, but instead a career changer who has mastered a little of both in the best case, but without being perfect at either.

KN: I don't agree. Both users familiar with business practice and graduate computer scientists are as important as ever, except that the roles are shifting and low-code developers can do much of the work for which extensive programming knowledge and experience is less critical. The fact that low-code developers are often career changers is more due to the fact that the depleted job market can't muster sufficient numbers of computer science graduates to meet the demand. It is a good thing that low-code has created a field of activity in computer science that is comparatively well suited for late entry as a career changer.

LM: You said that low-code reduces the need for developers to manually plumb the depths of IT, but doesn't the use of libraries have the same effect in conventional software development settings? Libraries provide an easy-to-use interface and hide much of the complexity.

KN: Of course legacy software development is also maturing, to the extent that the use of libraries, standardized procedures, and interfaces, among other things, limits the need for in-depth manual intervention in IT. The difference is that the low-code approach typically protects developers from the details of the technology and architecture in a far more consistent way. Ideally, a low-code developer will exclusively need to deal with the business aspects. How this is then implemented in the technology is up to the platform. Of course, this is also an idealized goal that we can only approach step by step, but low-code has already taken us quite a long way.

LM: Can you ensure data protection and data security with low-code?

KN: Data protection and data security are self-evident basic requirements for today's IT systems. Unlike individually programmed IT solutions, which depend on the strengths and weaknesses of the programmers who write the code, low-code embeds data protection and security. In other words, low-code helps to improve IT security, not undermine it.

LM: This assumes that the low-code platform itself does not pose any security risks. But we all know that there is no such thing as error-free software. Accordingly, a risk could also emanate from the low-code platform itself, which the user, who is not familiar with the source code, can neither identify nor evaluate.

KN: That's true. Even low-code platforms are not bug-free, and vulnerabilities in low-code platforms can impact many applications very quickly. But doesn't this apply equally to all the libraries, interfaces, and middleware functions that conventional programs rely on? We do not believe that the theoretical possibility of being able to view and check the program code that will ultimately be used offers more security than moving these security requirements to the low-code platform as a standard software tool that has been tested and hardened by security experts and is in actual use by many customers.

To minimize the remaining residual risks, it would be a good thing to test and certify the platforms against standardized security specifications. At the Low-Code Association, we would welcome that, and perhaps we can help to support such initiatives.

LM: You are the chair of the Low-Code Association board. What are the Association's goals?

KN: One of the Low-Code Association's most important goals is to dispel reservations about this new technology and promote technological progress among the general public. We want to help remove obstacles and demonstrate the benefits – especially for large and critical software solutions. And of course we also want to make a small contribution to giving what are often small- to medium-sized low-code providers based here in Europe the opportunity to demonstrate their enormous capabilities. Technologically, we have nothing to hide in comparison with the big players in the software market.