Assess your use case first before committing to Low Code/No Code, writes James Pring, Ebix Europe Sales Director

Back in the good old days, when computer programmers wore lab coats at work, the computers they programmed understood little other than arcane and complicated languages. Written in binary, or something else that may as well have been Latin, few people could master them, and application development took an age, costing a fortune.

These days we have a vast smorgasbord of programming languages for more rapid and cheaper application development, many of which are becoming increasingly more accessible to mere mortals.

Among the impenetrable jargon, you may recognise the terms Low Code and No Code cropping up quite regularly these days. Both of these approaches aim to speed up application development by either dramatically reducing or completely eliminating the need of traditional computer code that only trained programmers can understand.

You may have even used No Code yourself without realising it. Anyone who has developed a website using Wix, GoDaddy, Squarespace, or numerous others, will have actually completed a very complex programming task that would have once required someone with considerable coding experience and skill, not to mention the graphic design.

So some of the Low and No Code platforms out there are very good indeed, and not just for websites either.  Mobile apps, CRM, data entry, automation, accounting, reporting, BI graphs, and all manner of business functions can now be rapidly developed with little or no input from the traditional IT department.

Which sounds great, doesn’t it? Well, that depends.

Low Code/No Code, or LCNC for short, is not without its downsides. Whether these are material to you or your business, however, is a function of a number of considerations and every application, use case and environment is different.

Some of the key considerations are performance efficiency and speed, long-term maintainability, and ownership and control.

Performance

In allowing the user to either write less code, or none at all, it is the LCNC platform that writes the code instead. It does this by providing the developer a drag-and-drop, join-the-boxes graphical approach to the application design, which is then translated into a normal computer language behind the scenes. Then, the computer turns that into binary so it can run it.

It’s a bit like ordering a meal from Just Eat. All the consumer needs to know is how to choose, chew and swallow, leaving everything else to a number of layers providing delivery, order processing, cooking, sourcing ingredients and growing them in the first place.

It is widely reported that LCNC-generated programmes can be less efficient than handcrafted code that has been designed and stress-tested by an experienced programmer. This is hardly surprising as those additional steps can burden the computer with far more generated code than is necessary, and they can be less flexible in how they approach any given problem. And this slows everything down so the end result can be applications with laggy response times, poor scalability and a dislike of crunching large quantities of data.

But how important is that to you? If your application is not regularly wading through huge databases, or being used by thousands of users concurrently while still demanding sub-second screen response times, it may well be that any inefficiencies are irrelevant to you.

But an inefficient, slow and poorly scalable strategic system with a large user base and a complex data set is going to weigh very heavily on business operational efficiency. And the only way to try to mitigate that is to spend more on horsepower with the hosting provider. But even that won’t necessarily solve the problem, so you could end up with a slower system with exasperated users that’s costing a mint to host.

All computer applications can suffer from performance issues at scale, of course, regardless of how they are developed. But, with traditionally coded applications, they can be refined, tweaked, and optimised by the programmers to iron out the issues because they have access to all of the code right down to the nuts and bolts. With LCNC, however, this is not always possible as developers have access to only some of the code, or none of it at all.

Maintenance and cost

Despite the hype and the ambition, in our financial services world LCNC is not generally used by ‘Citizen Developers’ with no development training. More often, it is used by developers skilled in the particular LCNC platform in question. And they are proportionately quite rare people as compared with the millions of programmers worldwide with skills in more traditional programming languages. And they can charge accordingly.

To compound the problem, when you commit a system development to LCNC, you are taking a risk by becoming beholden to its manufacturer, entirely dependent upon them to stay in business and keep up-to-date with maintenance releases, support, and so on. If you back the wrong horse, you’re saddled with a big investment in applications developed in an unsupported LCNC that only a dwindling handful of expensive people can understand.

Worse still, LCNC code and definitions cannot be migrated to other LCNC systems so if yours turns out not to be the right choice, you’re stuck. Some systems permit export of the generated code for traditional programmers to use; such code is often very hard to maintain as it has been written by a computer, not a human being, and was never intended to be hand-maintained.

Ownership and control

Computer applications are, by and large, either built in-house by the end user, or built by a software company and licensed to the end user. In the former case, the user has full ownership and control of the system. In the latter case, they have somewhere between less and none, depending upon the licence terms and the client/supplier relationship.

With LCNC, however, an additional and absolutely critical component is added into that equation – the LCNC platform itself – which needs to be there both to develop the system and, in the vast majority of cases, to run it. But the LCNC platform is neither owned nor controlled by the end user, or their software provider, and it is highly unlikely that that will ever change.

Unlike our market’s end users, who regularly licence software from vendors, our central market utilities have a strong and growing desire for ownership and control of its systems. Whether that’s right or wrong is a matter for another debate but, given the above, it seems unlikely that LCNC is a great fit for that strategic desire.

In conclusion

So, although LCNC is almost certainly a very useful tool for the development of non-strategic, non-mission-critical applications, it is far from certain that they should be used in the development of larger critical systems, especially those utilities at the centre of our market as, in summary;

  • LCNC can neither be owned nor controlled by its licensees, nor can its vendors be
  • LCNC developer resources are relatively scarce compared with traditional programming language developers
  • LCNC vendors are, in all but a handful of cases, considerably smaller and less well-established than the global mega-technology companies we put our faith in for our operating systems, databases and such like
  • LCNC code cannot be transported to other LCNC systems in the event that migration is needed
  • LCNC online and data handling performance is likely to be slower than traditional methods and mitigation is either expensive, difficult or impossible

I would suggest, in conclusion, that caveat emptor applies here more than ever. Research your use case and your prospective LCNC very carefully indeed. And if the emptor is a London Market utility provider looking for ownership and control of its central market systems, playing host to tens of thousands of users conducting millions of transactions each year, the use of LCNC at all may be questionable.