Why the world needs Low-Code
And why I believe in the vision of low-code.
I am writing this because there still seem to be misconceptions about what low-code is, what it solves, and what it doesn't solve.
Low-code does some amazing things, and after working with low-code for about 5 years now, I thought I’d share my (as unbiased as possible) thoughts.
Are you wondering if you should adopt a low-code solution in your company, or become a low-code developer, then this blog is for you.
What is low-code (according to me)?
No long-winded intro, let's get straight into it.
For me, low-code is: “any tool that enables non-developers to create software solutions”.
This could be anything from Excel, Squarespace, or Mendix.
Low-code won't and isn't trying to replace traditional code!
Traditional developers often argue that low-code won't ever replace the complex code stacks that they are building, and unfortunately for them, I agree!
Low-code platforms enable the non-developers in your company to step away from basic tools such as Excel and start building software that can leverage your current IT landscape with things such as SSO and centralized data.
This also nudges the so-called “citizen developer” away from building system-critical shadow-IT and, instead, turning their knowledge into a resource your IT team can leverage.
In short: Instead of seeing low-code as a competitor, you can choose to embrace it and enable non-developers to create solutions that work for them.
The challenges of IT.
Some of the biggest IT challenges that companies are currently facing are:
- How can we make building software efficient?
- Where can we find good people?
- How can we streamline communication between business needs and software developers?
Efficiency
The problem
The goal for any business is to get the most done with the least amount of resources. IT is no different. If you can get more done with fewer resources, this allows you to solve more problems while having smaller teams (see talent acquisition section).
Solving efficiency is not a single solution but the combination of multiple smaller solutions resulting in “doing more with less”.
The solution
Low-code platforms increase efficiency on a couple of fronts:
- Less rework due to better communication
- Reusable patterns & processes (such as SSO implementation, APIs, database management, and deployment)
- Reusable third-party widgets & integrations
My (un)biased opinion here:
According to specialists, low-code platforms allow you to build up to 60% faster than traditional code. While I don’t know how you’d benchmark this, I have witnessed the speed of low-code myself, and a lot of it stems from the platform doing a lot of the heavy lifting.
Because low-code platforms do quite a bit of the heavy lifting, this allows so-called business engineers to create solutions instead of having to rely on traditional developers that don't always speak the business language. This can result in teams being smaller, which in turn increases communication.
Most organizations also use similar software packages, so creating an integration with Outlook is as simple as downloading a module and setting up the configuration. No need to reinvent the wheel.
And lastly, processes such as cloud deployment, version control, or updating & creating a new project are governed under a “single-click” principle, allowing your team to focus on building solutions instead of managing overhead.
Talent acquisition
The problem
Finding good people is always a huge challenge in any field, and IT is no different.
On the opposite side of this problem, a lot of processes are being automated through digitalization, and knowledgeable experts in your company are slowly becoming obsolete.
If only there was a way to retain all those years of knowledge and redirect it into your digital transformation…
The solution
The way low-code solves this is by enabling the amazing non-developers you already have to create solutions that work for them.
Because low-code platforms have a lower learning curve than traditional code, it is easy to re-train people within your own organization.
An added benefit of having developers that understand the business is that they are able to leverage their knowledge and creatively solve business problems (instead of focussing on just the technical problems).
Not to mention, you can get more done with smaller teams (see previous section).
Communication
The problem
Communication is hard. It is even harder if the team building the application and the team using the application communicate in completely different ways.
Rework is often seen as the biggest expense in IT. According to a study, 35-50% of the world's global IT budget is spent on rework. A lot of this can be solved through better communication of business needs.
The solution
Low-code solves this in two ways. The first is enabling business developers to bridge the gap in communication between the needs of the users and what should be built (see previous section).
The second part is that a lot of the moving parts are visual. It is fun to discuss solutions in the abstract, but having something visual to point to, aids in the discussion, allowing problems to be solved early in the development stages.
My (un)biased opinion here:
Something that I first noticed when working with low-code teams is how strong the communications skills were of low-code developers.Most low-code developers have a business-facing role, they look presentable, communicate clearly, are able to identify business needs, give valuable pushback when needed.
What low code doesn’t solve (yet)
Internal alignment
I often compare low-code to having a sports car, sure you go drive really fast, but if you are driving really fast in the wrong direction this won't help your business, this is not the car's fault, and not something a car should solve.
This is also visible in any development process. The good thing with low-code is that you will be able to know sooner if the direction is correct or not.
Usability patterns
Most low-code solutions have awesome UI libraries that make creating beautiful UIs possible, some even allow frontend developers to greatly customize the look and feel.
But UI is not UX.
If you don't follow proper UX practices, you can have a beautiful UI that is still unintuitive to use.
“UI is how it looks
UX is how it works”— Jason Teunissen
Infrastructure and architecture
It doesn't matter how simple the tool is that you are using, you are still going to run into architectural issues if you don't plan things out correctly.
This is even more so if data is stored in multiple locations. Having an experienced architect in your team that understands your traditional & low-code IT landscape will help solve issues before they arise.
The “leaning too much in the platform” trap
There are often times when there are conflicts of interest, the business wants to build quickly and solve a problem, but the user needs certain interactions.
The out-of-the-box solution is quick to build (often within a couple of seconds), the solution that the user might need is often possible, but might take a day to build, which often results in the business choosing the quick (cheaper) solution.
My (un)biased opinion here:
Depending on whether the solution is B2B or B2C, I often advise spending 90% of the team's resources on out-of-the-box functionality for B2B.
For B2C it can range anywhere from 60%-90% on out-of-the-box functionality.
The developer mindset
At the end of the day, you are still building software, and this requires a certain mindset. “How can I create a certain functionality, and where can I proactively find resources to help me?”
This might mean going onto forums, asking other experts, joining a community, following tutorials. Having a developer mindset is not something that any tool can solve, even though some are now using AI and predictive technology to help you create better applications.
Would I go back to traditional code?
I am often asked “would you like to go back to traditional code” and for me, this is a hard question. I have been on both sides of the fence. Both have their pros and cons. When working in a traditional code project, I miss the speed and visual side of low-code, but sometimes in low-code you can feel restricted by always trying to leverage what the platform does well.
I think it is important to understand what you want to solve, and then choose the right platform. For me, I am still mostly working in the corporate landscape, so choosing low-code seems to be the way forward for me.
Should YOU learn to low-code?
- Do you build Excel sheets to automate specialist processes? Yes, you are the main demographic and gain the most from learning low-code.
- Are you someone that likes logic puzzles, and is not afraid to use a computer? There are currently not enough developers in the world, this may be an amazing career opportunity for you.
- Are you a traditional developer? Then, you might have a harder time enjoying low-code platforms. That being said, having IT experience can help you land in a leadership role such as an architect, UX designer, or consultant within low-code teams.
I often ask coders: do you get joy from the act of coding, or from creating a product that helps people (or both)? This question can help re-evaluate what you love/hate about your job.
Feel free to reach out
There are some great low-code communities out there.
If you have any specific questions, feel free to leave a comment, or reach out to me on LinkedIn. I love helping people, and if I can't, I will try to point you in the right direction.
If you live in Holland, Germany, Belgium, UK, USA, Australia, or NZ and are interested in low-code, definitely contact me on LinkedIn.
(Big thanks to Ryan Mocke & Jan de vries for proof reading this blog)
