Low-Code and No-Code is growing exponentially these days. They both hold the promise of allowing software development companies to deliver more. No-Code’s promise is that you don’t need software developers to create software. In a world where it’s almost impossible to find qualified software developers, this is a compelling proposition for obvious reasons. Low-Code again promises you that your existing software developers will become more productive, and such becomes an alternative to hiring more people to deliver more product. Obviously, getting more value out of your existing resources should be interesting. However, what should you chose? Low-Code or No-Code? The answer is as usual provided by the infinitely wise Winnie the Pooh. Winnie was asked if he wanted honey or chocolate, his answer was “Yes please!”
When confronted with two choices, there is nothing that dictates you have to chose only one. You can just as well chose both. No-Code is amazing, allowing non-technical people to deliver fairly complex software. This allows you to engage the people whom are closest to the problem into solving the problem. Obviously a person that understands the problem is better fit at solving it, right? However, it suffers from lack of flexibility. There will always be edge cases where No-Code doesn’t allow you to solve a problem.
Low-Code again can in some extreme cases make your existing developers 100 times more productive, while also allowing your developers to dive into the code where it’s needed, when confronted with a problem that your Low-Code solution of choice doesn’t allow you to automate. No-Code and Low-Code hence lives in a symbiotic relationship, where the problem faced with by one of these constructs, is perfectly solved by the other construct. For instance …
Do you really want to have a No-Coder design your database?
For any serious software developer having studied database theory in university, the answer to the above kind of gives itself. Learning complex and abstract theories such as “single source of truth”, database normalisation theory, etc, simply isn’t within reach for the average no-coder without spending months or years to study the concepts. Most apps needs a database. Regardless of how well you abstract these concepts away using visual database designers, such as our SQL Studio – There will always remain something that requires a deep understanding of theory that’s simply not within reach of the average non-technical person.
I personally have a love / hate relationship with WordPress. Setting up a website with WordPress is ridiculously simple. Even a non-technical person can easily create a WordPress website, install Elementor, and create fairly rich and complex websites in a handful of days.
At the same time, it’s almost absurd how much additional markup is being created by Elementor and WordPress. Creating a website with Elementor instantly makes it 5 times larger in size, and it becomes ridiculously complex to take control over your HTML, to add custom logic to it. This of course reduces your flexibility and also makes it much more complex to ensure the website is SEO friendly. I would know, I am writing this article from our WordPress dashboard.
Most of the “plugins” in WordPress that claims to solve some problem, are actually solving problems that wouldn’t exist if you weren’t using WordPress in the first place. For anybody having knowledge about SEO for instance, all SEO plugins you can find in WordPress are for the most parts perfectly useless and redundant if you understand SEO and can control your HTML. Giving a software developer with SEO knowledge control over the markup generated, would probably facilitate for 100 times better SEO than whatever any WordPress SEO plugin could possibly result in.
Anyways, I am moving sideways here. The conclusion I want to emphasise is that when asking yourself if you should invest in Low-Code or No-Code, it’s not a binary choice. You should leverage both of these constructs to some extent. Where you use what, depends upon your organisation and your employees’ skillset. For instance, if all your developers have no idea about SEO, or you don’t have developers that are strong in HTML and CSS – Go for WordPress. WordPress is more of a “No-Code tool”. If you have a lot of developers that understands SEO and have strong knowledge about HTML and CSS, using WordPress is probably not a good idea.
Use Low-Code where you are strong, and No-Code where you are weak.
And yes, before you ask, I regret that we implemented WordPress in Aista. However, at the time, we found few real options, and we also happen to have knowledge about WordPress – So as we started using it, it seemed to be the natural choice. However, things change … 😉