Why we avoid low-code platforms
Recently low-code and no-code platforms have become more and more popular. The idea being that “business people” can build apps by dragging and dropping components around the screen. The advantage is that organisations can develop apps without needing the cost of developers and the need to maintain code.
The problem is that low-code is a bit of myth. The need for non-developers to create apps is often not-real and can cause business problems with security, management and scalability.
At Perrio we are a community of developers, designers and project building fans and we see some of the low-code benefits as bit myth.
Here are our reasons why:
What are these apps?
When we talk about building apps we are often talking about lots of different things in the same breath. At one end of the scale are the customer facing, business critical apps and at the other are the internal team apps that help but are not essential. It is important to understand what sort of app we’re talking about so we can understand who should be building.
As a general rule the more important an app is to the organisation, the more important it is for it to be built by software developers. Our quick checklist to identify an important app is:
Will there be a problem if this app fails?
Will customers use this app?
Will this app contain data that would be a problem if it was leaked?
Will this app need to grow in the future with new features or functionality?
If any of these are true then it is not suitable for a low-code platform. When customer facing apps fail or there is a data breach the reputational damage to the organisation can be massive so specialists should always be used to develop these apps.
Adding features
A common scenario with low-code platforms is that an app is built, people like it and so the organisation wants to add new features. The problem is that low-code does not lend itself to clean architecture and version control so adding new features becomes a high risk process. As more and more functionality is added the risk keeps going up since renaming a field and adding something, somewhere might have a knock on effect elsewhere.
Eventually it will become too expensive and risky so the app will be rebuilt with custom software, meaning the organisation is paying for the app twice. That rebuilding process can also be difficult to do. There are rarely clear requirements for a low-code app since it has evolved over time and so someone needs to reverse engineer what it actually does. Gradual migration is often impossible too since a low-code platform may not allow external integration, that means you need to invest a totally new app, then switch over one day and hope everything works.
Allowing a low-code app to grow means the work of replacing it is growing too. Eventually it will have to be done and the longer it is left the worse it will be.
The “Business People” are building Apps
The first part of this myth is the idea that the wider organisation is building apps. We do not believe in this distinction between the “business people” and the “technical people” (don’t they all serve the business?) but if we accept that people who are not software developers are building apps then the question is who are they?
The most common places to see low-code apps are tools built internally by teams to help their work. There might be a marketing team that has a campaign tracker or a finance team than has a data tool to help their work. These are good uses of low-code but when we look closer at the process we see the problems with the development.
Often the development is done by one person in the team, normally a fairly junior person who has a bit of free time. There are no requirements, they just set off and build something that will help their boss. That can be fine but if that person leaves or is too busy to work on the app then what happens if something changes. Imagine a finance app that was built by someone who left, then a tax rate changes, how can that be changed? In a development team there would other people who could look at the code and read the documentation to change it but low-code makes that hard.
Even worse than one person in a team building low-code apps can be external teams building them. We have seen projects take place with external development consultants delivering a low-code solution. Often the low-code approach has been prescribed by the client because they think it will be cheaper or easier to manage in the future. The consultants are often professional software developers who know this is not true and would rather just build a high-code app but they are constrained by the client. This is the worst scenario since the project is expensive, the solution is poor and the app will not really meet the business needs.
The reality is that the “business people” are not building apps, they are passing the work to external consultants or junior members of the team. This work is not free, people still need to be paid the solution that is produced is not going to meet all the organisations needs.
So what is role of low-code?
Low-code is great for testing ideas and very small scale projects. If you want to quickly validate an idea then low-code is great. If you want to build a very small tool that will help you but is not essential then low-code might help.
A better way
The need for low-code is present because it is hard and expensive to do high-code development. Often a high-code solution needs a budget assigned, test assurance, infrastructure to be assigned. The result is that people will naturally do what they need to do get the job done.
A better approach is to make high-code easier to do. We suggest organisations that want custom software need to do the follow:
Employ some software developers so they are available then needed
Create a project planning method so teams can request the developers build something and can see the priority
Recognise that custom software needs continuing care to patch, support and improved it
Building software can be inexpensive and offer a great solution for all sorts of businesses. A team like Perrio can manage this process and give you a product that really delivers something special for your business.
Low-code is a poor solution to the difficulty of high-code but we think that a better solution is to make high-code easier.
