No-Code Low-Code vs. Traditional Development in the Software Development Process

Hi, it's Kamil Tarczyński, and welcome to another episode of our podcast, Just No Code. Today, we'll briefly compare traditional programming approaches to No Code and Low Code approaches. We'll start with some theory, then discuss the potential of these approaches. This will likely give you a better understanding of the actual differences between these two worlds.

Theory and Potential of No Code and Low Code

So, starting with the theory, why is No Code, Low Code considered a faster approach? It's because if we program in the traditional way, we have to write all our code line by line. This makes the process of writing each line and taking care of it simply more time-consuming.

Differences in Approach

It's also a completely different level of abstraction because, for us, humans, if we can't see something that is visually clear to us, but instead it's a jumble of text, it's not immediately clear to us. We have to bite into it, read it, understand it, and mentally process it to understand what's happening. No Code looks a bit different because in No Code, we build the visual interface from ready-made elements. That means we have a blank white A4 sheet onto which we place elements - whether they're buttons, texts, or graphics. So we immediately see what it looks like. This is called the WYSIWYG - what you see is what you get - approach, which is very clear to us. We don't have to delve into what the code looks like underneath; we immediately see what our page, which we just built, will look like.

Simplified Programming and Faster Implementation

Underneath, if we obviously want to add some functionalities, which we definitely will want to, it's a bit easier again. It's another level of abstraction in programming that is more readable for us, humans. Because here again, we build from ready-made blocks. We have, for example, a workflow that if a user clicks on button X, then step one, step two, step three will occur. This is very clear to us, allowing us to understand the application and build it faster. Underneath that block is actually 50 lines of code, but here it's just one block that we simply add, configure by filling in fields, and we have a ready workflow.

Reusing and Copying Solutions

Another issue is that just as in programming, in no-code we can also reuse, copy, clone certain things. However, in programming, if we copy a piece of code, we have to make sure it will integrate with the rest of that code. In no-code, we can also copy workflows and will need to adjust, but again, we copy an entire workflow, which is a lot of different steps, and we need to adjust minor details so it fits properly into the application, which again is much, much faster and simpler. We can also copy an entire application very easily and just change its appearance, its styling, or minor things to make it a completely different application.

Simplifying Deployment

And of course, in traditional approaches, this is possible, but in traditional approaches, if we copy something and want to deploy it, we have to prepare the entire infrastructure, everything else, so that it works properly. In no-code, it's enough to attach a domain to this application on most platforms and click one deploy button, and we have it placed on our infrastructure, because we don't have to take care of that infrastructure.

Hosting and Infrastructure in No-Code Low-Code

In no-code, most platforms offer hosting. That means just as we build sites on various site builders, which I'm not comparing here because those are much more trivial, simpler things, here on no-code platforms, it's enough to just click one button, because underneath we already have some infrastructure, we pay a monthly subscription for some infrastructure, for some of its capacity, and we just place our application there. We don't have to worry about the whole configuration.

‍

Security and Scalability

And here we come to two very important aspects, namely the security of the infrastructure and its scalability. Just as in the traditional approach, we must care about the security of the infrastructure or the security of the application, which we will discuss shortly. Here, we have the advantage that the infrastructure we use in NoCode is well-configured. We have the appropriate certifications, as all these platforms have ISO, SOC, and other certifications, which simply attest that they are good, scalable, and secure infrastructures. Why scalable? Because each of them uses AWS or Google Cloud underneath. This ensures that they are scalable and secure, and we don't have to worry that if thousands of users suddenly access our application, it won't cope. It will simply scale underneath if we've allowed it to, just as if we placed our application in the cloud.

‍

Application Ownership

Many people ask about the ownership of applications built on no-code platforms. In the traditional approach, it's clear. If we wrote the code, it's our code. Nobody has any claims to it; it's simply ours. On no-code platforms, the situation looks a bit different because we generated that code using a platform.

So, what does it actually look like?

It looks like we obviously don't have rights to the platform itself because it belongs to someone else, but we do have full rights to what we generated on that platform. This is the case, for example, with Bubble or Xano. However, if you want to know exactly how it looks from a legal standpoint, I refer you to the terms and conditions where these things are very precisely described by the creators of these platforms, and where you can get acquainted with them to see if, for example, your legal department says it's okay or not. However, the ownership of the application is 100% yours.

‍

Possibility of Code Export - no code low code

And at this point, someone might ask, okay, if it's mine, does that mean I can export the code that was generated underneath? Unfortunately, I have to say that it depends. Some platforms allow you to export that code, modify it, place it elsewhere; some platforms simply do not allow code export because they are built in a slightly different way that does not enable it. Again, if ownership of the code, having that code is crucial for you, you simply need to acquaint yourself with which platform allows it, how it exactly works, and whether it's the right solution for you.

‍

Security and Application Performance LCNC

And one thing that these two approaches have very much in common, that is, the traditional approach and the no-code, low-code approach, is that always, despite having security of the infrastructure, scalability of the infrastructure, and good coding practices preserved, we, as the developers of these applications, must ensure the security at the logical level of the application, that is, at the level of the application itself. We must determine who will have access to what type of data. How users will be able to log into our application. What they will see in this application. How they will be able to manage those data and, of course, we must also care about the proper performance of this application because if, even in a no-code application, we place 500 different searches at the start of loading the page, it's clear that the application will run slowly because even the browser will limit us to making only 6 requests at once. So, before it makes 500 requests at once, it will simply have to take a while. Therefore, we, as developers, will still need to care about the performance and scalability of our application.

‍

The Advantage of No-Code Approach Over Traditional Development

So, let's say, what potential do we gain from this no-code approach compared to the traditional approach?

Mainly, of course, it's about time. We can build scalable, complex applications as well as MVPs much faster. Does much faster mean that we can generally shorten this process several times? Not exactly. From our observations, the entire process of delivering applications is shortened by about 30-50%, depending on the complexity of the project.

Why by that much if we build so much faster? Because we must remember that the process of building an application, here I refer you to our episode in which we talked about what the application building process looks like, is not just development. Development is part of the process of creating an application, but this process also includes a workshop phase, a design phase, a testing phase. These phases last the same in both approaches; we only accelerate the development phase. So, of course, we save a lot on it if we can save from 30 to 50 percent, but we still won't accelerate this process tenfold or fivefold, as you might read in many marketing materials from various agencies.

According to us, that's simply not true.

‍

How much does no-code actually speed up software development?

This process can't be accelerated that much because that would mean we'd have to skip all other processes and only compare the development times themselves. Then, of course, in some very specific and very simple cases, the development process could indeed be accelerated that much, but with more complex solutions, it's just not realistic because even if we're creating an application in no-code, we have to think about how to build it properly according to best practices, take care of its security, consider how the application's logic will be distributed, how it will function, and so on.

This process is very complicated, as I said, I refer you here to one of our episodes where we talk about this very thoroughly. But here you can also see a chart showing exactly what it looks like in the traditional approach versus the no-code approach, and draw some conclusions from it.

Thanks to this, of course, we're able to enter the market faster, we're able to gather feedback from our users more quickly, which allows us to iterate on our application faster, deliver value to our users faster, rebuild relationships with them, and this simply increases our metrics, which will affect whether our application will be successful, whether our internal users will want to use it, whether it will deliver real value to our company.

I hope this episode was helpful for you. That's all from me today. Bye!

‍