As is often the case with tools, execution and result depend on the users – of which low code development is no exception. So a non-developer with low code platforms can create useful digital services, but also a developer with the same platform can create output that is not accepted by users. Nevertheless, programmers are still irreplaceable because they have the basic knowledge and understanding of architectures that are necessary for full implementation and integration. Where exactly, the article shall show.
Low code cannot abstract everything
There are enough application areas where the low code reaches its limits. This could be the implementation of Android wallpaper or an iOS lockscreen widget, for example, because low code developers have limited access to device APIs and platform controls. So if you need access to special functions of native APIs, low code alone will not do the job. So low code is suitable for a large number of use cases and business processes, but just as a hammer is not suitable for putting a light bulb in a socket, so low code is not suitable for every use case.
Low code will therefore not replace developers. But that alone will not make them active supporters of low code. While some people appreciate the time savings, others do not trust Low Code on principle. They do not believe that Low Code can be trusted for business-critical processes, or that Low Code can be used for something over which they have no control during operation. However, this is also an irrational and unfounded concern.
Most platforms run on stacks known to developers. And most developers work with code and applications anyway, where they don’t have full access to all details. Java, Scala, Groovy and other programming languages are based on JVM, for example. JVM, however, when it was introduced, had to struggle with just as many prejudices on the part of the developers as low code does today. Over the years, however, the trust has grown. Developers began to realize that Java and JVM would remain with them for a long time and that Oracle would continue to support both.
The dependence on open source software can also be compared to a curtain through which one can look, but not see everything clearly. Just think of Linux or Ruby on Rails. Developers do have access to the source code, but to find rare problems, they have to analyze the code in depth. If you follow the analogy, low code can also have errors that need to be analyzed in depth, but it does not have a unique selling point.
Low code development is not a threat
Low code platforms neither threaten developer jobs nor are they the only black box developers work with. However, a basic understanding of how they work can help to identify potential errors before they occur.
So what remains as an obstacle? Perhaps the fact that many developers do not see their job as a profession alone, but work with open source codes in their spare time, develop new frameworks or try to solve previously unanswered questions. So the rejection of low code often has an emotional component, because low code development can be implemented in much shorter time than software engineering. So accepting low code platforms means accepting a cut in personal status, as well as the fact that low code platforms solve many complex problems in advance: load balancing, resource allocation, encryption and the like. This leaves them with only a few hurdles to overcome in everyday life, only a few exciting problems that they still have to solve manually.
Coding vs. Low Code?
For many companies, low code is an important component for the business to maintain sustainability and to be able to compete against other competitors by quickly adapting to the market. Development with low code is a straightforward process and is usually faster than previous development processes. Often IT is the bottle neck in the digital transformation, as it is more important than ever, but it is also a finite resource. It is also susceptible to human error. Often enough, there is an unpleasant correlation: if developers try to write code very quickly to keep up with the requirements, they usually build in more errors. Simply programming faster is therefore no alternative to low code.
Low code development offers quality and speed in one - for a reasonable price
Even though speed is essential in constantly changing markets, speed often comes at the expense of quality. Low code reconciles both, but comes with a decisive disadvantage. Existing low code platforms are not freely available, but cost high license fees depending on the intended use. They promise to make up for this with lower development costs and fast implementation speeds.
Leadership: Inspiring employees to rethink
To ensure that developers accept working in a low code environment and that no acceptance problems arise, a fundamental rethink should be encouraged: Away from self-identification solely as a developer and towards the self-image as a “leader”. These look at the big picture and not just at their role in the company. Leadership is not limited to management positions, but everyone can and should participate.
Leaders recognize that they are not there to solve or even “hack” problems, they are responsible for delivering products. So pride and status should not be defined by job title or work alone, but by the effect he or she has on others. According to this self-image, it can be best for the entire organization to work with a low code environment, which results in many satisfied customers, because to insist on “that’s the way we’ve always done it”. This process of rethinking must therefore also be encouraged.
The communication of company goals can make it easier to place personal tasks in the overall context, show connections and promote acceptance. When developers realize that the goals are bigger than they are, they can be equipped with the appropriate leadership tools, giving them the opportunity to participate in the big picture. If low code development is an essential component in the corporate vision and employees recognize that the result counts more than the means or the way to achieve it, they will also be willing to work with low code.
If low code is initially met with rejection, the question of why should be asked and the underlying reasons and fears identified. These fears are real, but can be dispelled. If this is successful and teams use low code tools effectively and with enthusiasm, then companies will quickly achieve the corresponding success: Satisfied end customers and their users.