"Low-code" continues to be in the spotlight - and causing debate. Many programmers argue that the supposed improvement in the development process can interfere in a negative way and even result in inferior applications while others are concerned about the security implications that may arise from this new way of coding.

To be clear, the inevitable result of low-code is not necessarily complexity. As with traditional application development, it can and often is part of the product codebase lifecycle; while not inevitable, it is common. There are, however, many steps that can be taken to reduce the complexity of applications, regardless of how they are built, in order to improve performance, scalability, availability, and the speed of innovation.

COMPLEXITY IS REGARDLESS OF APPROACH

Yes, an application created with low-code, like all applications, can become complex and require the use of simplification techniques, however these problems are not linked and exist equally significantly in regular product development processes.

In fact, what low-code increases is the amount of code that was not written directly by the development team itself. There is more of what was automatically generated by the platform or included in libraries necessary for the application to work, but these lines were not the product of the team.

Thus, it would be correct to say that there is usually more “unfamiliar” code in the application, when this type of tool is chosen. It should be clarified that "unfamiliar" is not the same thing as "complex". In fact, it can even mean the opposite.

We see, then, that by simplifying the cognitive load and time pressures on developers, low-code allows professionals to focus on the big picture, the business logic, rather than wasting energy on the details that are automatically resolved by the platform. In addition, the best environments often use standardized, tried and true techniques to complete low-level tasks while minimizing the possibility of error. Auto-generated code and library code are developed and improved long before reaching the IT staff. Opting for a low-code tool ultimately results in greater overall use of standardized coding techniques, industry best practices, and, ultimately, more software reuse.

BUT WHAT ABOUT COMPLEXITY?

Increasing the use of standardized coding and leveraging software reuse are common strategies used to reduce the complexity of an application. Standardized coding reduces the cognitive load involved in understanding how an application works, and code reuse tends to reduce the number of moving parts that can fail. As a result, the application created with low-code tools will be less complex and potentially more reliable than the functionally equivalent one developed using traditional programming techniques.

This analysis is not new or unique to the low-code space. Software abstraction has been used to “hide” code complexity from developers for decades. Whenever you use a higher-level language like C, Java, Ruby or Go, the actual code that is created and executed to perform the desired actions is abstracted. We focus our development on “top-level builds”, allowing the compiler or interpreter to handle the details of creating and executing machine code.

Going further, when it comes to using higher-level software packages, environments, and frameworks, you are also abstracting complexity so you can focus on higher-level features. So using Ruby on Rails, Spring, Hibernate, Gin, jQuery, Bootstrap or even HTML/CSS, the process is the same. The result is more powerful applications and greater reliability, with less development effort and lower support costs. This is not unlike the arguments discussed in the low-code community today.

The world of software development is complex, with new challenges emerging every day, and as such, developers regularly make use of tools, resources, environments and techniques to make the whole process easier and simpler. Recently, low-code platforms have been improved and become a useful and safe tool to optimize work efforts, without adding undue complexity to the application.