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

The Fundamental Theorem of Software Engineering states that "We can solve any problem by introducing an extra level of indirection."

We learned in part one of this series that higher-level languages such as JavaScript provide a programmatic abstraction layer to reduce the complexity of building solutions that take advantage of complex technology. Over time, low-code/no-code tools offered the promise of a visual abstraction layer, hoping to reduce the complexity of coding in higher-level languages. But, we also know that levels of indirection and abstraction layers are no silver bullet for software engineering.  A corollary to the Fundamental Theorem of Software Engineering states:

"We can solve any problem by introducing an extra level of indirection; except when the problem is too many levels of indirection.”

Introducing abstraction layers does not come without cost. In the current age of software engineering, visual abstraction layers such as those offered by many low-code/no-code tools often reduce flexibility and come at a higher cost of change. Choose your abstraction layer carefully, mindful of the cost of change.

With the right partner to help navigate the millions of repos available on GitHub, choosing a robust starting architecture from the start means that an application can evolve along with the open source projects it relies on.

While low-code/no-code solutions may mean that a project can go from idea to production relatively quickly, the performance and security issues may not begin to materialize for some time. While many solutions try to implement best practices and update their solutions, once the customer base and use cases become larger wholesale changes become dangerous.

What started as a solution with one purpose will inevitably be used in ways never imagined by the original developers and changes that affect how the solution behaves can have consequences unforeseeable by devs.

With change come security vulnerabilities. At some point the drift between the original implementation and modern best practice becomes vast and these solutions are no longer the most performant, most secure way to do things.

It's absolutely critical to the health and evolution of an application to think about change as it relates to building an application. The question to ask is: “Are the tools and technologies that have been chosen going to allow for enhancements and evolution or just allow for building on top of the existing application?”

While there are countless GitHub repositories that are no longer maintained, working with a strategic partner who is familiar with open source and knows the landscape is invaluable.

A strategic partner knows what to look for, as well as how to inspire an organization and its employees to take ownership of enhancing the open source projects they are using. Using a strategic partner can mitigate the risks of choosing the wrong technology for a project.

Furthermore, using open source means that if one or more of the dependencies in a project becomes outdated or insecure then it doesn't ruin the entire project. It means there’s an opportunity to find or create a better solution to that specific issue and enhance the performance and security of the entire application.

The best way to reduce or manage cost of change is to build software applications with secure and performant microservices and not get locked into a monolithic, co-generator that has a very narrow point of view.

Apart from reducing cost of change by being at the forefront of technology and security the potential to improve profitability is greater.

It’s not hard to see the appeal of the low-code/no-code solution — it would be great if there was one way to do things.

If this were the case then low-code/no-code could work, but that's just not the way that development works. There are multiple ways to achieve the same outcome, some are more robust than others, and the definition of robust may change over time.

We’ve made the case for why using open source is a stronger solution than low-code/no-code. But we aren’t the only ones to see the value of open source. There’s a lot of investment into open source projects from major tech players, such as Google, Amazon, Microsoft, Oracle, IBM, etc.

At NearForm open source is at the core of our values . We’re active contributors to Node.js, in addition to supporting the internal development of great open source projects such as Fastify , Lyra , Pino and Clinic.js among others. And we use the projects we develop in our client projects.

Organizations looking for a partner should be asking, "How does that partner harness open source in a secure way, especially in the enterprise?" The statistic is that maybe up to 90% of the code in most modern applications is open source, but that hardly anyone may be actually managing it as a true open-source program.

In addition to understanding the landscape and developing real-time opinions on technology stacks, a strategic partner can help organizations make sure they are managing dependencies and versions, and know when it's time to move on from a library.

Great strategic partners will ask their vendors how they manage the open source projects they use and look for ways to optimize and improve their processes while building the capability within the company to continue along the path once the engagement is finished.

At NearForm, we have the dependency checking built into the repository and a lot of automations that help clients manage the open source projects they’re using in a strategic way. We impress upon our clients the importance of managing the code of the application and empower them to manage their open source code.

Strategic partners that are familiar with open source will also have an excellent track record of contributing to the projects they use in client projects, supporting their developers to create and innovate new ways of doing things and actively work towards improving open source for everyone.

Choosing to build with open source projects can reduce cost of change and improve profitability in the long run but that should be seen as an added benefit (along with performance, security and modernization) rather than the driving factor behind the decision to go this route. It's important to find a vendor that respects the open source ecosystem and how open source technologies interact with one another rather than finding a vendor that exploits the open source community and says, "Look, this is a way to build complex stuff for free and get stuff out there."

Often business leaders are seduced by the concept that low-code/no-code solutions are easy solutions that can greatly reduce costs or the need to hire expensive developers. An experienced strategic partner should say, "Well, let's really talk about what cost really means and focus on cost of change because you could try this low-code/no-code solution and you might get something out of it. You might build something, but then you're going to suffer to maintain it."

To maintain that competitive edge organisations must be able to adapt when the environment has better solutions for them.

The open source community has grown steadily over the past decade. It has allowed innovations and optimizations that were built out of necessity for solving specific problems to be expanded upon and adapted for multiple use cases.

Layers of abstraction - we’ve had enough, and don’t need to introduce more. Let’s optimize what we have, for example, using AI.

All of this open source code is contributing to tools like GitHub's co-pilot , which is an AI-assisted programming tool built on the code available on GitHub. But co-pilot is not just spitting out boilerplate code. It's suggesting optimizations for the engineer.