Rethinking Low-Code/No-Code and Open Source, Part 1

Low-code/no-code solutions for business applications have been with us for decades, bringing custom solution creation capabilities to business users who want to quickly address sometimes complex needs. Many times low-code/no-code tools can appear to be a silver bullet that solves a problem, adds a coveted feature, or reduces cost in the short term. But, they can also handicap the future of a product or solution by making it less flexible, less performant, less secure, less maintainable, and ultimately more expensive to inevitably re-platform or modernize.

We spoke with NearForm Field CTO, Paula Paul, about her experience unravelling and re-platforming low-code/no-code solutions that have constrained organizations, to get some insights into how leveraging open source can result in the same kind of rapid delivery but also save organizations from the headaches of re-platforming and modernization.

Writing code requires specialized knowledge; it has since Ada Lovelace wrote the first computer program in the 1840’s. Early low-code/no-code solutions can be traced back to Cobol and Fortran in the 1950s, which were high-level languages that abstracted the complexities of machine or assembly language code and made writing programs easier.

In that sense, it could be argued that JavaScript is a low-code solution. JavaScript adds a robust layer of abstraction between the JavaScript runtime , making it easier for developers to manipulate applications and machines in order to create solutions for business needs. JavaScript quickly became one of the most popular high-level languages - just as COBOL did decades before.

When the information age exploded in the 1990s it brought technologies like HyperCard from Apple and Visual Basic from Microsoft. These tools were designed to abstract technical complexity and allow analysts closer to the business to build interactive applications through visual editors with little to no coding knowledge required. These tools provided an additional layer of visual abstraction so that little or no high-level language coding was needed at all. The programs produced by these applications may have looked functional, visually, and may have even performed the desired business functions. However, as more people began to use those applications, leading to more requests and different needs, maintaining or expanding upon those applications generated by low/no-code tools often became a challenge.

"We can go all the way back to the original Visual Basic, which I joke of sometimes as the root of all evils. Developers dropped widgets on a form and code was generated, but naming conventions weren't enforced and you often wound up with something that looked okay and worked but was not scalable or maintainable in the long run." Paula Paul, NearForm

Fast forward to today. There are many low-code/no-code solutions that tempt business leaders with the promise of quick wins, low complexity, and reduced costs, as the modern versions of Visual Basic.

While today’s solutions may target modern web platforms, with improved visual appeal and scalability, they can bring the same risks in longer-term flexibility and ability to evolve with business needs. It's fair to assume that when Visual Basic was created web and scalability weren't as important as quickly creating a functioning application. At the time, applications ran on desktops and an application developer’s ability to influence look-and-feel or scalability was limited.

Today, as languages grow more powerful and developers grow more creative, the solutions generated by low or no-code tools risk missing out on new developments and trends; they can easily become stuck in time, as with earlier low-code/no-code solutions. It’s impossible to ‘future-proof’ an application when technology evolves and improves rapidly, so it is critical to understand and focus on minimizing the cost of change. Low-code/no-code tools focused on rapid delivery of a prototype or Minimum Viable Product do not necessarily generate code that is easily scaled or maintained. The cost of change, and the chance of ‘lock in’ can be high.

Deploying a Remix site can be done with one line of code | (image from GitHub) In the early 2000s, no one could have predicted the role JavaScript would play in the modern web. Initially, it was a language that allowed frontend functionality and did that, oftentimes, at the cost of performance. Today, with Node.js, Deno, Next.js, React, Remix, and more, the JavaScript ecosystem is rich with options for end-to-end application needs. With a single command executed from a command line , we can now scaffold a fully functional application, complete with deployment pipelines, authentication, testing, linting, persistence, and more. With open source solutions like this, we only need to tailor those solutions to our own needs. This approach minimizes the cost of change and optimizes for maintainability.

According to the Linux Foundation, ninety percent (90%) of a modern application is assembled from open source software components. Today's developers often scaffold composable solutions from existing components rather than rely on code generated from a low-code/no-code tool. They then extend that scaffold with bespoke capabilities required to address specific business needs. This is very similar to the promise of low-code/no-code tools, but more closely aligned with the specific need, and more likely to evolve with the business.

"Moore's law is the observation that the number of transistors in a dense integrated circuit (IC) doubles about every two years." Moore's Law , Wikipedia.

This law has dominated the computing industry since 1965, with the speed and capability of computers doubling or more every two years as a result of increases in microchip transistor capacity. It held true for over fifty years. Although modern processors have evolved, we can still marvel that the computing power in the phone many of us hold in our hand is far greater than some of the most powerful early mainframe computers. The coming generations of processors will unlock even more power and opportunities for developers.

What does this mean for businesses? It means acknowledging what is built today must be made with evolution in mind. If an organizaztion is currently satisfied with its technology strategy and leveraging today’s practices, its competitors will have an advantage if they can more quickly adopt tomorrow’s advances. If businesses do not embrace change and evolution in their technology strategy they’re at risk of being rendered obsolete by companies that do.

"You may have a new line of business or a new growth spurt that requires scale, or you may hear of a new security vulnerability in the wild that you need to defend against. When you bring this back around to low-code/no-code those solutions can be very tightly coupled to a particular way of thinking. When the market changes, you're tightly coupled to the way that tool was originally designed, which could not have imagined these new things in the market today." Paula Paul, NearForm

Minimizing the cost of change allows businesses to pivot and extend their digital products to meet market demands.  Applications built on active and well-maintained open source projects benefit from the communities behind them that adapt the codebases to reflect the most modern and secure ways of implementing features.

Low-code/no-code solutions may streamline a specific approach, using today’s technology, to quickly deliver prototypes or Minimum Viable Products, but software is never finished. As product needs grow, modifying and extending that product often becomes a challenge when the tool ‘gets in the way’. Making small changes to an application that was generated from an inflexible tool can have unexpected consequences, negatively impacting users and constraining an organization's ability to serve its customers.

“Yesterday's shortcuts are today's nightmares. The race is quicker when we're stricter. Keep your eyes on today, and declare what you may.” Mark O'Brien , Actor

While taking shortcuts may help get an application up and running quickly, the long term consequences can prevent products and services from meeting evolving market needs and lead to disruptive and expensive changes when application modernization becomes necessary.

Application modernization is never a matter of if . It’s a matter of when . Understanding this crucial component of building software is fundamental. The longer a body of code remains in production without change, the higher the cost of that inevitable change becomes. The product or system architecture is not a fixed decision; it must be flexible enough to evolve and change with business and market needs.

According to Grady Booch, software architecture represents the significant design decisions that shape a system, where significant is measured by cost of change. If an organization's technology is outdated and also has a high cost of change, the business can't change. If the business can not change and adapt, it will not meet the ever-changing needs of its customers.

"It's in the decision-making process and those initial decisions, like low-code/no-code vs. open source. If you are not mindful of those decisions, you can wind up holding your business hostage to inflexible technology. And the best way to de-risk being held hostage by your technology is to really understand and harness the open source ecosystem, and focus on minimizing the cost of change." Paula Paul, NearForm

Find out more about how to understand and leverage the open source ecosystem to meet your customer needs, create strategic differentiation, spark innovation and pave the path to modernization in the second instalment of this series.