It seems like everyone in IT is talking about low-code. Throughout the Covid pandemic, many companies have been hard-pressed to deliver new digital applications. So, with a limited pool of experienced programmers available to take on projects, a new class of digitally-savvy knowledge workers is taking software development into their own hands through the low-code approach.
Whereas traditional programming involves more hand-coding and customization, low-code platforms tend to favor visual programming models and common components. Neither approach is superior—each has unique benefits and caveats. While low-code offers unparalleled usability and collaboration potential, traditional coding affords greater control and flexibility.
So how is a low-code approach different from traditional software development? And when should an organization opt for one or the other? In this article, we’ll compare the two methods. We’ll identify the advantages and drawbacks of traditional development versus low-code and identity use cases to help decide when to apply each in practice.
Traditional Software Development
Traditionally, software has been constructed by experienced developers. Applications are hardcoded in a programming language, such as PHP, Python, JavaScript, Go, or C++. Applications are comprised of functions that use language semantics to perform various actions. Though traditional development involves much manual work, it is often supported by code libraries and frameworks. For example, many apps utilize a frontend framework, such as React.js.
Hand coding requires deep programming language knowledge, but that is only one aspect of modern software development. Most applications interact with data, meaning that the software will rely on an underlying database system to store and access data. Engineers may opt for an open-source database option, such as Neo4j, PostgreSQL, or MariaDB. Businesses must host the application somewhere and ensure access to only authorized users. For this, developers turn to Cloud Service Providers and standard authentication solutions. Note that this cursory overview does little to depict the entire range of full-stack software development considerations. The types of stacks are endless. Plus, since APIs are the building blocks to modern applications, these integrations must be hard-coded as well.
Software can’t be immutable—it must be released and maintained over time. In traditional development, a modern deployment process will likely involve a CI/CD (continuous integration/continuous delivery) process to analyze code updates for bugs or vulnerabilities, and deliver them safely and automatically to the cloud host. This software must also be versioned carefully to avoid broken clients. When you’re hardcoding from scratch, you must also consider a wide range of device-specific hardware constraints, such as web browser standards or native mobile app requirements. As part of the software lifecycle, monitoring production runtimes is essential to provide ongoing insights that can be utilized to improve the platform.
Pros of traditional development
- Far more granular control and customization
- Better scalability
- Less dependency on proprietary assets
- Greater use of open source technologies
- Better for tech companies
- Ability to deploy wherever
Cons of traditional development
- Harder to get started
- Lack of guardrails
- Competing ideologies make it confusing
- Need to assemble entire stack from scratch
- Lack of automation increases development time and effort
- Must version and update over time
Low-code Development
Low-code development is different, as it typically uses a third-party platform that automates many traditional development headaches. In this paradigm, developers construct applications and workflows using pre-configured plug-and-play components. Most of these low-code platforms adopt a graphical user interface, making it more possible for non-developers to drag-and-drop common functionality and connect workflows visually.
A low-code platform also often handles the surrounding software lifecycle, from code generation to database setup, testing, deployment, and authentication. A low-code development platform may host the software or automatically publish your application to a select cloud provider. In either case, it usually means deployment is only a click away. By automating regular tasks, low-code can free up professional developers to work on more demanding projects. Due to its usability, low-code appeals to a broader base of potential users, enabling the citizen developer concept.
There are many low-code platforms on the market today. Examples include Mendix, Veracode, Outsystems, Quickbase, WaveMaker, ServiceNow, Zapier, Indigo.Design, EasySend, Tray.io, Adalo, Retool, Formstack, and TrackVia.
All these services vary in usability and approach. Some are 100% visual-based, appealing to the business class of no-code users. Others are intended to work more closely alongside a professional developer’s established workflows, supporting IDE plugins and constructed with developer-friendly languages. Others use proprietary languages—for example, WS02 utilizes its home-brewed Ballerina language for its low-code integration platform. Such proprietary formats may accelerate the platform goals but limit portability elsewhere.
Pros of low-code
- Empowers citizen developers
- Can quickly generate applications
- Reusable templates
- Acts as a collaboration center for a company
- Frees up developers to work on less tedious tasks
- Automation for the entire software lifecycle
- Enables operations, business, project managers, analysts
- Helps retain agility amid low talent access
- Can jumpstart digitalization
Cons of low-code
- More locked into vendor paradigm
- Less customization potential
- Templates do not consider edge cases
- Limited in functionality to what the provider supports
- Integrations are limited to what provider supports
- Still requires time to train citizen developers
- Opens new security concerns
- May introduce shadow IT
- Requires centralized governance model
- May still require IT for customizations and local integrations
- Could usurp existing developer talent
Traditional vs. low-code scenarios
1. Healthcare Intake Forms
Suppose a medium-sized regional healthcare provider wants to automate the tedious process of patient intake. They want to digitize the process across their branches and replace their manual pen and paper forms with a cloud-based solution. Since the operations team can’t get ahold of their programmers, tech-savvy operations choose to build out this functionality on their own using a low-code platform. In a matter of days, they construct a form, insert the correct fields, and host it at a unique URL for new patients to access. Data is accepted and stored automatically in a database while retaining privacy following HIPPA guidelines. Once they prove the prototype works, they show it to higher-ups, who assign a developer to build a webhook that automatically syncs the data into their core record-keeping systems.
2. AI-Based Audio SaaS
A high-tech company wants to get into the artificial intelligence market with an AI tool to automatically identify and reduce white noise in field recordings. They scour the market for a low-code platform with the relevant audio algorithm, but they find nothing that fits. They decide to train an algorithm on TensorFlow, utilizing their own recordings as well as open-source datasets. Once the algorithm is well-tested and ready to be commercialized, the company decides to serve their product via HTTP endpoints and finds a relevant API manager to monetize the service. The team attempts to loop in low-code automation to generate the UI for their landing page and user onboarding, but they abandon it as the templates are too rigid—they look like other landing pages on the market. Instead, they opt for a custom design, since they possess front-end talent to create responsive pages using open-source frameworks and documentation generators.
3. Manufacturing Floor
A quality assurance manager for a bottling plant needs better performance insight across multiple factories. They also want quality engineers on the factory floor to view any issues and diagnose problems in real-time. The factories have sensors installed, but no standard way to aggregate sensor data into visualizations that are also shareable in the cloud. The manager lands on a low-code platform that integrates with industrial IoT sensors to automatically consume data and populate visualizations. Since the data windows are strictly for utilitarian internal purposes, the manager doesn’t care much about the UI design. The end result increases awareness of manufacturing operations, helping technicians to reveal bottlenecks to improve efficiency.
Flexibility is key
From the hypothetical examples above, differing use cases can produce wildly different requirements, which will dictate the amount of software automation used. Some projects, such as the factory floor scenario, might be entirely possible to construct using low-code builders without involving software programmers. In contrast, like the form idea, others will only get 90% of the way there but require an inevitable handoff. More advanced concepts, such as a nuanced AI-based Software-as-a-Service, are likely not a good fit for low-code platforms. Such developer-facing software with heavy customization and high backend complexity is probably too nuanced for low-code to handle.
Low-code/no-code tools can provide more immediate gains for common tasks and inspire agile innovation among a brand new class of digital thinkers. Proponents of this approach argue that individuals with field expertise outside of software development, such as analysts, scientists, and researchers, will especially benefit from the ability to quickly spin together internal applications. This could greatly encourage, say, a financial data scientist, to leverage a pre-built neural network to analyze social trends.
On the other hand, low-code platforms still will require hands-on training to fully leverage company-wide. Introducing low-code use for non-engineers will require onboarding and application security training to mitigate the potential security risks. Low-code also introduces a significant dependency on a single platform provider, which may be too tough to swallow for some groups, as it could inhibit flexibility. Many software requirements are simply too nuanced to a company’s particular needs, making working within the confines of a common platform too much of a burden.
In summary, it’s good to realize that software development has always involved automation. We have added abstractions on root binary code, operating systems on top of that, and programming languages on top of that. Now, low-code is yet another abstraction layer and tooling option for the developers of tomorrow. And, as with any approach, real-world business outcomes should dictate its usage.
