Low Code. A convenient distraction ?

By February 15, 2021March 25th, 20212 Comments

Why No Code/Low Code application development may not be the panacea to traditional development woes.

Technology evolves at a speed quite unlike anything else, particularly so in extraordinary situations such as the time we find ourselves in right now.   With change and trends come new solutions and products, some of which continue to evolve and grow – such as customer platforms like Amazon  – and some slowly disappear into oblivion – such as Palm OS.    Low Code/No Code may well be one of the latter.

According to Forrester, the global low-code application development platform (LCAP) market size is set to increase to $21.2 billion by 2022, up from $3.8 billion in 2017. As such, it may seem rather arrogant to contradict such a forecast to say that LCAP is not the silver bullet solution for solving traditional dev stack bottlenecks.  LCAP uses pre-built modules in a visual environment, enabling developers and end-users the ability to design simple programs to expedite the way they work.   Or does it? What looks like a quick win could possibly just be diverting us from the glaring truth that nothing of value can ever be created without coding.  

Do developers even like low code?

It must be remembered that there are always fundamentals that must be understood to make the process of software development sustainable and scalable.  There is, in fact, a very valid reason why full-stack development platforms such as dot net exist.

Despite the user-friendly façade, developers often find in reality that low code is often slower and more frustrating than writing their own stack.  Issues including ongoing maintenance, configuration and debugging problems combined with the sheer weight of the tools can make LCAP more onerous than beneficial to an IT team.  Because of the shortfalls, developers end up spending just as much time, if not more,  learning how to work with LCAP platforms.

Low code perpetuates a siloed approach.

Beside the IT practicalities, good management principles espouse unification, collaboration, governance and standardization.  Although LCAP might produce fast results for end users, each of those new apps works alone.  Much like a personal excel spreadsheet which brilliantly captures our personal formats and formulas, LCAP apps might be beneficial for one or two but meaningless to the business as a whole.  Perhaps LCAP is not the panacea we all first envisioned?

“We wanted to build a low code app to assist our employees to book desk space at our various offices around the world.  Given the amount of travelling, and now the number of employees working remotely, we are able to reduce our physical office footprint and effectively rent desks in our offices to our staff.    

With no experience in coding, we were able to develop a solution using LCAP quite easily and were pleased with our results.   That is until we realised how much data the app consumed and given that we are charged on a consumption model, it became too expensive to roll out the app across enterprise.”  

Even had the new app in the example above had been affordable, how would LCAP handle the business logic?  Where do we find the list of staff in each office?  How do we prioritize staff for a given desk?  How do we charge back the desk time consumed to various departments?    LCAP technology does not work with the business holistically and, what’s more, will not deliver a sustainable enterprise solution.   After all, end-users are not there to develop apps – they are there to use technology to add value to a business.

Are we too quick to swallow this magic pill?

Indeed, LCAP brings hard coding development to the masses, to provide a quick and easy solution to some of the drawbacks of building of traditional development stacks.  But are we too quick to swallow this magic pill?  Instead of a bandaid approach, perhaps we should instead focus on recreating the traditional development environment to provide the full capability of high code, with the simplicity of low code.  If such a development platform was front-end based and hence faster to learn and build on, surely we could achieve the benefits of both traditional development stacks and the ease and speed of LCAP.    For although there may always be a place for LCAP, nothing can replace the bespoke quality and brute flexibility of traditional development.   

Why Ikon is a better alternative

The Ikon Platform was officially launched in 2019 to orchestrate data within an ecosystem to deliver a wholistic view of a business in real time, by uniting all data sources.   But in addition to eliminating silos and extending the life of legacy systems, it provides an exciting new framework for building.     Ikon can therefore be considered a third option for app development, which combines the flexibility of high code with the simplicity of low code.

Because all development tools are native to the Ikon platform, building new apps involves the re-use of core building blocks to speed the time of development using a graphic workflow interface.  Regardless of the language in which a developer is familiar, Ikon allows building with them all, using a variety of databases.   Working primarily in the front-end like this means the platform is quick to pick up, with graduates learning how to build in as little as 8 weeks.   And because the building blocks can be added and removed as the needs of the business evolve, it can natively be referred to as low code while still offering the complete advantages of a full stack.

Rather than being distracted by shiny objects such as LCAP, the focus around development platforms should instead be to understand how we can re-engineer the full development stack to deliver the speed, flexibility and scalability that is so desperately required.  Ikon by Keross, launched in 2020, is already turning heads as the sustainable third alternative to both high code and low code options by combining the benefits of both.  

Join the discussion 2 Comments

  • Joel Martin says:

    I think the take in this article is interesting and I feel there are some good points in it, however I also see the focus on LCNC (versus LCAP) as a swift way for light coding or process centric coding to benefit organizations. LC as a core app dev solution – as I read your article – likely would be a bit bloated and not nearly as clean as developing code based on traditional development stacks. The time saved for both the end-user and the customer for what LCNC can deliver will be too compelling to pass up.

    Expect heavy lifting, and tools developed with LCNC initially to be queued into longer development times. Meanwhile MVPs and disposable (often changed) workflows, analysis, and user centric apps may indeed benefit from the advantages that LCNC will bring. Think VHS and beta or Apple’s Swift versus Objective-C. Sometimes easier coding or a more technical solution is better, but mass adoption closes the gaps very quickly as people innovate and build on it.

  • I have read several excellent stuff here. Definitely value bookmarking for revisiting. I wonder how much attempt you put to create such a wonderful informative site.|

Leave a Reply