The Trade-Offs of Using low-code Platforms
Hardly a day goes by without someone asking whether low-code tools like Outsystems or Mendix are suitable for developing their applications in, or if they can use a tool like Tosca or Katalon to automate their tests in. The answer, as always, is “it depends” :-).
Whether a tool is fit for purpose or not depends on the context in which it is used. Low-code platforms provide an abstraction layer that removes the need to learn coding, design patterns and their associated best practices and pitfalls. It is essentially a framework on steroids that allows you to very quickly create a simple application or record automated tests. One way or another the tool translates your design, or the recorded test, to code. This can be in its own proprietary format, but more commonly it outputs Java or .NET code.
On first sight, you may think “that’s great! Now I can edit the code myself and continue development!” until you realize why we use design patterns, architectural constructs and naming conventions. They are there for the benefit of the developer and that machines are not very good at generating well-structured human-readable code.
Developing software is complex. There is no single best way to implement or change a certain feature. Development is always a trade-off on the amount of effort you spend; whether you just want to push out features as quickly as possible and live by the motto “after me the deluge” or if you (and your team) are creating maintainable, highly performant and extendable solutions. The latter means your code has to be readable and maintainable by humans (other than yourself), something that disciplines like Domain-Driven Design try to accomplish.
As a rule of thumb: low-code platforms are an excellent choice if you quickly need to develop an application that you will use for a short period of time, that is not iteratively updated and that will be thrown away afterwards. For example, they are perfect for creating a simple stylized data collection tool to support a marketing campaign or for a proof-of-concept. If you are creating software to support your core business processes and/or you plan to extend its functionality in the future, I’d always opt for having full control over all programming constructs so that you can leverage the full potential and make conscious design choices from which you will benefit now and in the future.