Slowing the Low Code Hype Train

Here we are with another new calendar year opened up, and you’ll be forgiven if January ’22 has you the same you were at this time last year with some sense of bewilderment at how developer technologies and methodologies are expanding in leaps and bounds. Part of that has been low-code technology, one that was forecast to have gains in application around 22% for 2021 and by all indications did that at the very least. It’s also estimated that by 2025 70% of new applications will be built with low-code or no-code technologies.

What we have on the plate today is 3rd generation low-code technology that’s improved on the 2 preceding generations of it. It gives enterprise that ability to build anything from the simplest to highest complexity applications and scaling them to whatever extent needed without limitations. It’s also known for providing built-in controls and functionalities required for enterprise governance while fostering more collaborative team working environments too.

It is conducive to the type of digital applications enterprises need to be able to create quickly and then easily adaptable as they fit needs that may be changing. Here at 4GoodHosting we imagine we’re like any good Canadian web hosting provider in that we’re able to see the real relevance in that and accordingly why there’s so much hype about low code and applications that are built around it.

But perhaps there’s reason to pull on the reins a bit there

The Pros

Low code can be helpful for building an MVP and fleshing out concepts within a small scope with precise product requirements and an understanding any scaling will be limited. But many times as project progresses there is the need to upgrade the processes. Without low-code solutions your ability to scale is very limited, and it can also be more costly too.

Then from the developer’s perspective choosing low code to complete small-scale projects and prototypes or build basic solutions is almost always faster and with fewer hiccups. Keep in mind though that most professionals will prefer to code from scratch when working on complex on account of the flexibility that provides for them. While the chance that a low-code platform won’t allow you to create a product meeting new or changed requirements will exist, that’s usually no deterrent.

Scalability really is the key benefit for low-code development, and the opportunity for and cost of horizontal and vertical scalability are primary factors when a vendor is being chosen. The benefits for accommodating changing numbers of daily active users, available features, storage, and expanded computing power are considerable and weight heavily in favour of this type of development.

It also allows you to escape being overruled by AI when a site experiences a large of influx of visitors and you would otherwise have access limited and / or forced to upgrade. This a huge issue in the SaaS sector right now and it’s one that’s pushing developers there to have greater interest in going low-code moving forward.

The Cons

Starting at the start here with the drawbacks to building with low code, it is extensive training requirements. There’s usually a lot that goes into implementing a low-code solution and how that usually manifests itself is in significant delays in deployment. For many people the foreseeing of this is what leads them to stick with agile development in order to get to market in a timeframe that’s been envisioned for the product.

The next issue here is timeframe variances related to other factors aside from development tools and methodologies. Ones that vary from weeks to months and will depend on the quality of the available documentation and support. The fact there isn’t an industry standard means every platform will have its own unique system. If an industry standard did exist that would change things instantly, but of course the question who would define that, based on what criteria, and what authority to do so?

Troubleshooting is difficult with low-code development too. When something goes wrong it a successful remediation will depend on the quality of the documentation, the response speed, and the competence of the dev team and their support. Debugging a program built with low-code may be difficult or flat-out impossible too, and vendor lock-in is a possible negative too if the solution will not be compatible with any other competitor or similar provider.

You may need to depend on the vendor’s platform to work, and you may only be able to make use of it as a backup. Plus migrating to another service is many times nearly impossible. You may well have to start over again from scratch.

One Tool Like Others

The simplicity and scalability of low code make it appealing, but it shouldn’t be seen as the be-all solution that should be rolled out by default in every task instance. Make sure you have a deep understanding of the niche you’re working in to foster strong understanding of the demands for the product you’re building and how they might be tested against a vendor’s capabilities.

Post Navigation