Low code has received a lot of press recently. There seems to be quite a debate about whether the use of low code makes the application development process better or if it interferes with the development process, resulting in inferior applications.
I read an article recently that talked about how an inevitable outcome of using Low Code was application complexity. Further, this application complexity leads to increased difficulty with security issues.
This article got me thinking. I’ve been writing a lot about application complexity recently and some more about low code. However, the correlation between application complexity and the use of low code was an interesting perspective.
Complexity applies equally to low code and traditional programming
To be clear, the inevitable outcome of low code is not necessarily complexity. Just like regular application development, complexity can and often does make its way into the lifecycle of the product code base. While not inevitable, it is common. There are many things you can do to reduce complexity, which improves performance, scalability, availability, and speed of innovation.
These same techniques apply to low-code applications as well. Yes, a low-code application can and often does become complex and requires the use of simplification techniques to reduce complexity. However, these issues are not tied to the use of low code. They are just as significant an issue in a regular product development process.
Unknown is not complex
What low code does increase is the amount of software that exists in your application that was not directly written by your development team. There is more software that was auto generated from the low-code system that was not part of the app-team-developed low-code. Thus, there is often more “unknown” code within your application when you use low-code techniques.
But unknown is not the same thing as complexity. Unknown code—code provided by someone else and added to your application—does not, in and of itself, increase the complexity of the application.
In fact, the exact opposite may be true.
Low code actually reduces the risk of complexity
Using low-code development techniques can actually reduce the likelihood of excess complexity seeping into your application. By simplifying the cognitive load that exists on the application developers, low code allows developers to focus on the bigger picture—application business logic—and not focus as much on nitty-gritty details.
What happens to those details? They are handled by the low code environment. Further, the low code environment will use standardized and normalized best practices to complete these low-level details. The autogenerated and library code is developed, tested, and improved long before your application team ever uses it. The more you use low code to build your application, the greater the amount of this pre-tested, standardized code that is in use within your application. The net result is using the low code tool to build your application results in an overall greater use of standardized coding techniques and, ultimately, more software reuse.
But what about complexity? Increasing the use of standardized coding and leveraging software reuse are two techniques that 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 in a complex application.
Overall, your low-code created application is less complex in accomplishing the same results using low-code compared to an application developed with traditional programming techniques.
How does reuse and standardization impact complexity?
When we think about the complexity of an application, we typically think about two different aspects of the application — the size and number of components that make up the application and the rate of change to the software of the application.
Increasing your use of reusable code decreases the size and number of components making up an application, and increasing the use of standardized coding techniques tends to decrease the rate of change for those particular modules, contributing to a decrease in the rate of change of the application as a whole.
The reality is a lot more complicated than this (pun intended), but the basic philosophy still applies. Increasing the use of standardized coding techniques and increasing the use of reusable software components tends to decrease the complexity of the resulting application.
This isn’t new
This analysis isn’t new to the low code space. We have used software abstraction to “hide” code complexity from developers for decades. Anytime we use a higher-level language, including C, Java, Ruby, or Go, we abstract away the actual code that is created and executed to perform your desired actions. We focus our development on “higher level constructs,” allowing the compiler or interpreter to handle the nitty-gritty details of actually creating and running the machine language code.
And it doesn’t stop with compilers. When we engage in the use of higher-level software packages, environments, and frameworks, we also abstract away complexity so we can focus on higher-level capabilities. So, using Ruby on Rails, Spring, Hibernate, Gin, jQuery, Bootstrap, or even HTML/CSS, we are abstracting away complexity in order to allow us to work at a higher level. The result is less complex applications, resulting in higher reliability with less development effort and lower support costs. This is no different than the arguments discussed in the low-code community today.
The world of software development is a complex one, with new challenges arising every day. Software developers regularly use tools, resources, environments, and techniques to make the process of software development easier and simpler. Recently, low code techniques have improved and have become a useful tool for improving the process of developing software without adding undo complexity to the application.
