Rethinking no code / low code
Tags: programming, code, nocode, lowcode
Published: 2021-01-17 14:24:28

# Introduction

Over the years I've received many requests to help a relative/colleague/friend build their app or website. I'm sure if you're a fellow developer reading this you've experienced the same.

I received such a request recently, and as usual turned them down when they told me their budget was a three course meal, at a restaurant of my choosing. 

The aforementioned request prompted me to investigate existing no code / low code solutions on the market today. 

## A look at Existing Solutions

I researched some of the more well known players like Honeycode (Amazon), Google app maker, Wix, Webflow, Bubble.io and some perhaps lesser known like Budibase. 

In my opinion they all share a common design flaw, in that the users they are targeting still require a basic knowledge or fundamental understanding of either design and/or development related principles.

They expect the users to setup their data models, relationships, automation and so on. In my experience the average business executive or business owner will have no concept what any of this means, so they'd likely still need to employ or contract a developer/designer to supervise them. It kind of defeats the purpose doesn't it?

In my opinion no code / low code solutions are absolutely merited, but I feel that currently they are targeting the wrong audience. 

## Why is no code / low code merited?

Consider the following two entities; a small start-up business and a local sports team. 

It is highly unlikely they have the budget to hire a developer for their website/app, so they will look to find a no code solution that can do this for them at a greatly reduced cost. And you know what? There is absolutely nothing wrong with that.

## General Consumption

If the existing solutions still require some degree of technical know how, then what is the answer to the question; *"How do we develop no code solutions for general consumption?"*.

The following sections highlight thoughts I've had to answering this question. 

### UI and UX driven data/architecture

Consider for a moment that the user is presented with a drag and drop interface, or a 'choose your template' interface. They've dragged a couple of input boxes, set one of them to password and added a button that reads "Login". 

Almost anyone looking at this will instinctively know the purpose is to login to their account. 

Doesn't this beg the question why the system shouldn't also instinctively know this? Why are we then asking the same user after they've selected this to then go and describe their user model for the database?

Why aren't we driving the behind the scenes architecture based on these UI/UX decisions that the user has already selected? I feel like we're asking them the same question in two different ways. So how can we eliminate this repetitiveness? 

### Natural Language Processing?

Could we explore [NLP](https://machinelearningmastery.com/natural-language-processing/) (Natural Language Processing) to aid with this. Or is this even necessary? Would it be too much to map common words to their intended usage?

Let's consider again the word "Login" as an example. Is it reasonable to assume that given this word we are safe to generate the best educated or recommended architecture, which would look similar to as follows:

 - Create a user table with username/email (or whatever is specified) and password.
 - Create authentication endpoint
 - Handle login, logout
 - If email then ask if they'd like email confirmation
 - Ask the user if they'd like 2FA with this
 - and so on and so forth..

Would this be a case of assuming too much? You know what they say when you assume too much.

### Conventionally Recommended

If we were to take such an approach we'd want it to be conventionally recommended. What I mean by this is go ahead and assume best guess, but then ask the user for feedback at every automated decision, without getting in their way. Something like "That looks like a login page. We've gone ahead and setup a structure for users in your app. Is this wrong? If so let us know and change it".

### Simplicity

In my opinion the targeted audience for these no code solutions want something simple and intuitive, so they can quickly put together their app for their local quiz league or inventory management. 

Using the aforementioned approach of UI first, with drag and drop selectable elements, I believe we can achieve this in the future.

### Collaboration

Another area I noticed many of the existing solutions lack is collaboration. In the scenario where a small team are using this, they'd want to be able to make changes without getting in each others way, and to be engaged with for every change or decision that is made. Show them updates in real-time as they happen, so they can collaborate and leave notes on what is being changed in their app.

### Version Control

This is another area sorely lacking in my opinion. From what I've researched the closest thing to version control any have are a revisions history section. 

Again, the average intended audience perhaps has no understanding of version control, so let's repackage it as 'backups' or 'snapshots'. If the user decides they want to roll back to a previous version, we should have no problem doing so.

### Summary

Thanks for reading this (if you've got this far). I understand this piece is mostly rumblings of a random mind, but I hope if you have any interest in no code / low code I've at least given you food for thought. Or perhaps this may help spike your interest in a sector that has a lot of potential to grow, and still plenty of gaps in the market, in my opinion.