According to Gartner No-Code and Low-Code will deliver 50% of all software projects in the year 2021. Even if these numbers are inflated, you’d have to be living under a rock to avoid noticing it is gaining traction, and it is gaining traction very, very, very fast. Hence; What exactly is it? Will it steal your job? And why should you even care?
The difference between Low-Code and No-Code
First of all, there is a huge difference between No-Code and Low-Code. No-Code is typically targeting “citizens”, as in people not able to create software systems themselves due to lack of software development skills. No-Code is often referred to as “citizen development” – Implying people without knowledge about programming language and software development theory can create software systems. No-Code is useful for simple customer facing frontends, with some interaction with pre-defined services, and simple database structures. However, we’re a far cry away from being able to deliver complex systems using No-Code, and I am not sure if we will ever reach that point either. Besides, even No-Coders requires low level modules and components to interact with, something typically accomplished by working together with a “real” software developer, churning out these components such that the “citizen” can orchestrate these components together.
Low-Code on the other hand is targeting developers, and can be seen as an extension to the tools we are already using, making us more productive and helping us deliver superior quality. Low-Code typically requires some coding after the automated process is done with its thing, and hence beyond what the average “citizen developer” can use. For these reasons a lot of developers will answer you; “I don’t believe in No-Code. Sure Low-Code might have some value, but not No-Code.”
In such a regard, Low-Code is just an incremental improvement of our current development models, and one could argue that even things such as NuGet and NPM are its ancestors – Simply because if you have ever used a package repository to manage libraries, you’ve arguably already been using Low-Code for a long time. Low-Code just implies the point where the tooling is so good that the computer automatically generate our code. Angular’s ng generate and CLI being one example of this.
In some ways Low-Code is for your codebase similar to Unit Tests, since it automates a part of your existing process, to ensure higher quality, faster iterations, and better products for the end user. The same way Unit Testing have automated the way we test software, Low-Code inevitably automates the way we create (parts of) our code.
While No-Code typically allows non-developers to use a GUI to drag and drop together functionality, visual components, and database connections – Low-Code on the other hand is typically using automated processes to read meta data from for instance your database, to generate code based upon your existing components, and/or data structure. Hence, although obviously related …
Should you be afraid?
If you’re a developer today, it might be easy to be scared of No-Code and Low-Code. Let me answer your fears with a question; “How many QA testers did your employer fire as you started creating Unit Tests?” The answer to the above question is (probably) zero. Unit Tests are incredibly important for a serious codebase, but they do not replace a human being doing QA on the product after the developer has done its job. Neither will Low-Code replace the system developer, quite the contrary, Low-Code increases your job security if applied correctly.
Low-Code and Product Quality
According to Gartner the average software project has only 29% chance of succeeding – As in being done on budget, with the anticipated features, within the timeline scheduled for it. This implies that 71% of all software projects are either flat out failing, and/or “challenged”. These numbers are simply insane. Imagine if 71% of all cars we manufactured exploded and burst into flames as we turned the ignition key?
This is the current state of software development. By automating as much as possible in the way we create software, we can significantly increase the above percentage. Unit Testing here is a proven concept in such a regard, and Low-Code comes with the same promise – Simply because a Low-Code component is typically being reused in hundreds and thousands of projects, and hence obviously more care have been given to its implementation, ensuring its quality and performance.
My personal Low-Code story
I was personally laid off a month ago. Initially I was scared, and I started desperately looking for a job – But after a while I realised it was a “blessing in disguise”, because it gave me that kick in the but I needed to start my own company, exclusively based upon Low-Code constructs may I add. The paradox is that I was actually laid off because of bad code quality. This wasn’t something that was my fault though, since I had inherited a nightmare of a legacy project, where 90% of its components was 10+ years old, in a monster of a codebase, with more than 1 million lines of such code. Hence, being Head of Development for such a project, was arguably like being the President in Hell – Sounds cool until you realise where you are … :/
Anyways, the paradox is that if my employer had been willing to use Low-Code constructs, we would never have ended up with such low code quality, and we’d been able to deliver much better products, on time, on schedule, with the features expected by management. Hence, the lack of Low-Code constructs, and the fact that I was denied to use such constructs, was the reason I lost my job.
Yup, as paradoxically as this sounds, it truly is true. If I had been heard in regards to my wish for using Low-Code constructs, my job at my former employer would still exist, everybody would be happy, and nobody would have been laid off. Hence, Low-Code is here to save your job. It’s really quite simple; You only get rid of people not delivering what you expect them to deliver. Low-Code increases your chance of delivering, and hence increases your job security. Deliver what your employer wants you to deliver, and he will never get rid of you.
How Low-Code works
To understand Low-Code is to understand that everything exposes meta data in some form or another. For instance, I can run a simple SQL towards your database, extract all tables, their fields, their types, and all foreign keys. This produces an extremely formal “specification”, created in a structured format, allowing my Low-Code scaffolding systems to produce working code, based upon this “specification”. For a lot of our job, the end result of such scaffolding processes is enough. For other parts of our code it’s useless. For everything in between those two extremes “it helps”. I still end up spending time manually changing things, and/or adding things after I have automatically generated the skeleton for my projects using Low-Code constructs. However, Low-Code makes me (at least) 10 times more productive.
The above is key, since if I had been allowed to use Low-Code constructs at my former job, we would have been able to deliver according to expectations. Instead, we got stuck in an ancient legacy codebase, impossible to improve, until we reached the point that the entire software development department was laid off in a month.
The irony … :/
Low-Code is here to save your job, not to steal it. Unless you can understand this, you’re in trouble, and you might not be able to sustain your current job – For reasons I illustrated in my last article. The reason why Low-Code is here to save your job, can be summed up by summing up some of its traits.
- Low-Code makes you 10 times more productive
- Low-Code allows you to deliver 10 times higher quality
- Low-Code makes your software 10 times more secure
- Low-Code often scales 10 times better
- Etc, etc, etc …
Fact are, Low-Code improves every single measurable aspect of your existing job by at least 10x. When you’re 10 times better on every single measurable parameter, it is highly unlikely somebody would want to get rid of you. However, if you continue to smash away at your manually created JavaScript for a couple of more years, solving commodity problems my system solves by clicking a button, I can pretty much guarantee you that your employer will wake up one day, and realise others are able to outperform you by 10x, on every single parameter we measure our software projects by today. At that point, it’s too late, and your job is gone.
Watch the following video where I illustrate how we delivered a Low-Code software project 1 million times faster than a manually created solution.
If you want to play around with an Open Source Low-Code project I have spent several years creating, you can play around with Magic Cloud below.
