One of the IT trends of 2016 is Low Code, which promises the ability to quickly fulfill customer demand without large armies of expensive IT personnel.
In fact, Low Code tools can supposedly be used by anybody, the so-called “citizen programmers”. That’s very convenient as developers are expensive and hard to find, and often lack business expertise. Does that sound familiar? If you were in IT in the 1980s and 1990s, chances are you heard the same promises about the 4GL technologies that were prevalent for about two decades but ultimately failed. Is Low Code doomed to fade like 4GL, or has it learned from history?
What is Low Code, exactly?
The term Low Code has been popularized by Forrester, which also ranks the top suppliers of Low Code. It defines Low Code as:
Platforms that enable rapid delivery of business applications with a minimum of hand-coding and minimal upfront investment in setup, training, and deployment.
So if there’s very little coding, how do you develop applications with those platforms? Per again Forrester, it’s:
Through declarative tooling that supports visual drag-and-drop composition.
The visual “composition” is one of the key elements of Low Code, but it’s also a bit misleading. Indeed, there’s no large amounts of difficult-looking text (aka code), making the development environment more accessible, but what’s happening is still programming.
These two factors mean that my colleagues and me (who get to analyze and consult on hundreds of software systems each year) only encounter a pretty low amount of citizen programmers for these technologies. Most are full-time developers and typically have a technical education, as it is for most technologies. It seems Forrester even calls the fact that Low Code platforms are for citizen developers a myth:
We rarely found these citizen developers in our research.
Who are these Low Code providers? Forrester mentions Appian, Mendix, OutSystems and SalesForce as the leaders in this field, but also traditional big names like Microsoft and Oracle have Low Code offerings.
And 4GL, what was that?
The name 4GL stands for 4th generation (programming) language. It refers to the concept that programming languages have evolved from low-level and detailed (1st generation, machine code) to a higher abstraction level with more power (3rd generation, most of the programming languages that we still know today). The 4GL name thus suggested more abstraction and more power. There were countless 4GL vendors, including Oracle (Forms), Progress, Clipper and Informix.
Like Low Code today, 4GL was supposed to make it possible for non-programmers to create application. In a 1982 book called Applications Development Without Programmers, James Martin argues that certain end users are perfectly capable of creating applications themselves and advocates the use of early 4GL technologies (such as RAMIS and FOCUS) for that. Such claims quickly helped 4GLs become popular, even if in practice very few applications ended up being created, let alone maintained, by non-programmers.
Although 4GL applications are still in use at many companies around the world, their popularity has waned since their introduction. The technologies are mostly used for existing applications, with very little new development going on. The reasons for this disappearance are closely related to three common risks for 4GL that I wrote about in 2014. Do these risks also apply to Low Code platforms? And are there any new risks?
4GL Risk #1: Poor support for large systems
In order to keep changing and growing a system, it is necessary for changes to remain localized as much as possible. 4GL technologies did not support this well, lacking support for concepts like abstraction and separation of concerns.
This is an issue that many high level programming frameworks suffer from, and Low Code does so too (see Neal Ford’s discussion of Dietzler’s Law). That said, today’s Low Code vendors do offer two improvements over their 4GL ancestors:
- The need to support abstraction and separation of concerns has been acknowledged, and features like inheritance, modularization and encapsulation are offered in many Low Code environments. This allows systems to remain more maintainable and flexible as they grow. In comparison to traditional programming languages, some of these features are still limited, though.
- As noted earlier, all Low Code vendors do have traditional programming as part of their solution. Low Code vendors are now generally open about where code is a better choice than their own technology. In many solutions, though, this code is hidden. I’ve seen Low Code solutions that turned out to have tens of thousands of lines of code hidden in the visual programming environment. While that doesn’t disqualify the choice of technology per se, these applications were definitely not low in code.
4GL Risk #2: Tools do not support development best practices
The tooling available to 4GL developers was limited, and only offered by the technology’s vendor. Most of the time, these tools did not support common development practices like version control, automated testing, building or deployment, leading to a lot of time spent on performing such tasks manually.
In the Low Code world, tooling is still almost exclusively provided by the vendor. The support for best practices has fortunately grown, and almost all offer some form of version control, although typically with a proprietary solution. Deployment is also taken care of, as the majority of Low Code suppliers also host the applications built in their technology. However, tooling is often still behind or non-existent for automated testing, continuous integration and use of static and dynamic quality tooling.
I am happy to report that some Low Code platforms are now offering APIs that allow third parties to provide additional support. For instance, we at SIG have used the API of Mendix to create an Application Quality Monitor that helps developers and managers to create highly maintainable Mendix apps.
4GL Risk #3: No libraries
Programmers often use 3rd party libraries to perform common tasks, such as calling web services or reading XML documents. This means they don’t have to program this functionality themselves and they often offer better quality as well. 4GL technologies have very low numbers of libraries and then mostly offered by the platform vendor itself.
Low Code suppliers have definitely improved on this, and actively support 3rd party components, typically in the form of an app store, such as the Appian App Market, the Mendix App Store and the SalesForce AppExchange. Some of these stores thrive and offer a large variety of free and paid 3rd party components but others are (so far) mainly filled with components provided by the supplier, thus offering little improvement over 4GL.
A new risk: Vendor dependency
4GL technologies created a strong dependency from its clients on the vendor. The technology’s systems can only be maintained, deployed and run using tools provided by the vendor, and often the system’s code or data cannot even be read or inspected by other tools.
This is also holds for Low Code vendors, but the dependency on the vendor is even stronger. In many cases, all or most of the tooling is only available online, and the applications themselves are deployed to the vendor’s cloud. While this offers many benefits, it also reduces flexibility. Using different tooling on the (visual) code is generally impossible, and hosting the application at a different provider is rarely an option. That may not be a problem today, but what if your favourite vendor suddenly hikes its prices, goes belly-up or discontinues the technology you use?
Looking at the Low Code suppliers, it seems that most have studied history at least a bit and know which problems plagued 4GL technologies. They have tried to mend these issues in their systems. But, in general, they have not been able to completely mitigate these technology risks.
How can you apply this knowledge in practice? When considering to use a Low Code technology for a new application, follow these two steps:
- Determine if Low Code is a good fit for your application. There’s no magic formula, but many Low Code vendors have a clear functional or technical ‘sweet spot’. Typical poor fits are systems that you expect to grow large or be long-lived — despite improvements over their 4GL ancestors—as are systems with large amounts of computation or algorithms. The lack of flexibility in deployment (only in the vendor’s cloud) may also be prohibitive depending on your requirements.
- If you’ve selected Low Code, make sure to analyze the vendors. Make sure you know the following about your vendor before picking one:
- What features supporting abstraction and separation of concerns do they offer?
- What tasks are typically relegated to traditional code on their platform, and how that coding supported?
- Do their tools allow you to use the development practices you adhere to?
- Do they have a community of libraries and how active is it?
- How likely is it that the vendor and the technology will outlive your application?
- How many experienced developers are available on the market?
Did I miss anything? Please share your suggestions or experiences on selecting a Low Code vendor.
This blog was also published on Medium by Jeroen Heijmans