A tale of two software development projects: a creative take on the history of app building tools.
Software development without a low-code platform
Leo is leading a small team on a legacy migration project. They’re migrating a Microsoft Access database to a custom web application. The mission-critical database tracks coffee consumption in the office. The requirements include:
- a Java (Spring Framework) server-side;
- an AngularJS client-side;
- user and entity governance controls for admins;
- a drag and drop form builder for end users;
- an OpenAPI Specification with documentation for all entities; and
- an integration with an Internet of Things coffee maker.
The organisation doesn’t have a low code platform, so Leo’s team begins software development, writing the code base from scratch.
The Chief Technology Officer (CTO) sends Leo a memo several weeks later. The organisation will use React for client side scripting going forward. Leo estimates the impact of this change to be several weeks and communicates this with his stakeholders, who are frustrated.
Several weeks later, Leo’s team finishes the project. They’re immediately handed another project with similar requirements. The only change is an additional feature for end users: dashboards. They start writing the code base from scratch, again. Leo’s team make several improvements to user and entity governance while working on dashboards.
After delivering the second project, Leo is contacted by the first project’s stakeholders, who ask if these updates can be ported to their app. They can be, but not easily. Even shared features have disparate code bases.
Leo is now stuck maintaining two similar, but separate code bases with uneven development cycles.
Software development with a low-code platform
Leo is leading a small team migrating a mission critical Microsoft Access database to a custom web application. The requirements include:
- a Java (Spring Framework) server side;
- an AngularJS client side;
- user and entity governance controls for admins;
- a drag and drop form builder for end users;
- an OpenAPI Specification with documentation for all entities; and
- an integration with an Internet of Things coffee maker.
The organisation has been using a low code, app building tool for several years. The platform they’re using comes out of the box with tools for writing Spring server-side and Angular client-side. Leo’s team begins modelling the target application in the platform’s diagram editor.
The bot for writing Angular has ready-to-deploy models for all of their requirements. This enables Leo’s team to focus on expanding Springbot’s range of extensions with form building (which will complete Springbot’s coverage of the requirements).
Several weeks later, Leo and his team have finished updating Springbot and are ready to deploy. At the eleventh hour, the CTO sends a memo. The organisation will use React for client-side scripting going forward. The memo contains documentation on how to switch from Angularbot to Reactbot. Leo ‘s team reviews the documentation. Reactbot already supports all of their requirements, which means migrating from Angularbot is a matter of days rather than weeks.
Leo’s team finishes the project. They’re immediately handed another project with similar requirements. The only change is an additional feature for end users: dashboards. Leo’s team uses models from previous work and deploys a beta version of this app within a couple of hours. Leo’s team make several improvements to the models for user and entity governance while working on dashboards.
After delivering the second project, Leo contacts the first project’s stakeholders and discusses Springbot and Reactbot’s new extensions. The stakeholders ask Leo if these updates can be ported to their app. They can be, and quite easily. After minor tweaks in the diagram editor, the bots are ready to update entity governance and add dashboards.
Leo can now maintain a single code base supporting multiple target applications. This enables him to add value, and continuously modernise multiple projects with each update. This increases the organisation’s momentum and enables the CTO to achieve their digital transformation strategy.
Is low-code a dream or a reality?
Low-code platforms are the IT industry’s newest and brightest trend. Reading the second scenario, where Leo and his team have access to such a platform, shows why.
Forrester estimates that the low code industry is already worth more than 4 billion US dollars and predicts a Compound Annual Growth Rate of 44%. At this rate of growth, the low-code industry will be worth more than 27 billion US dollars by 2022. The app development game has changed.
The low-code revolution is here; but maybe you’ve heard of no code platforms? Is less more? What’s the difference between low code and no code? Does low code vs no code?
Are low-code and no-code the same?
Most modern app building tools are lumped together under the banner of low-code; however, a split is emerging. Some platforms help developers be more productive and some help non-developers become developers.
The operative words here are ‘low’ and ‘no’. A low-code platform offers a method for creating software with minimal coding. However, low-code platforms are usually piloted by developers who add custom, hand-written code where required. No-code platforms, on the other hand, promise the ability to create an application without writing any code.
Typically, a low-code platform places no restrictions on a developer’s creativity. After all, things which are unsupported by the platform can usually be completed manually. This is not the case with no-code platforms.
No-code platforms are sometimes called black boxes. You can execute actions on your provided interface, and code is generated as a result. Why and how this code is generated is generally unclear. In this scenario, augmenting your code base manually is nearly impossible.
Low-code and no-code are similar, both help humans write code, but one helps developers be more productive and the other helps non-developers become developers.
The low-code and no-code revolution
Low-code and no-code are high on every CTO’s mind; however, these are hardly revolutionary ideas. They’re simply new names for an approach to building apps dating back as far as 1982.
An interesting turn of events in this space is the rise of multi experience development platforms (MXDP), potentially the next evolution in the low-code narrative.
5 reasons why CTOs are choosing multiexperience development platforms
But why are these platforms exploding in popularity now? What’s changed since 1982? And can history provide a glimpse into the future?
The short answer is these app building tools have matured, and now provide more value. This increase in platform maturity has been coupled with an equally important rise in business need.
The rise of low-code platforms has coincided with demand for low-code platforms. Digital transformation is no longer a ‘nice to have’, but a must have. Organisations are increasingly aware of the need to continuously modernise their processes and technologies.
The immature app building tools of yesteryear have given way to more advanced platforms with stronger offerings.
This is the history of app building tools. From its origins to multiexperience development platforms.
The origins of low-code and other types of app building tools
Software development without software developers
The idea of developing software without software developers has been anticipated since at least 1982. James Martin published a book called Application Development Without Programmers, outlining why and how such a world could come to be.
The world James (and many others since) paints promises businesses two things:
- faster delivery; and
- reduced IT personal.
James believed end users were capable of creating their own applications, providing they had access to an app building tool.
Armed with a way of writing code (without actually writing code), end users could become citizen developers. Who are employees who can create and maintain apps they use in their daily operations.
Citizen developers are domain experts. Because of this, they’re perceived to hold a number of advantages over traditional (ergo, professional) software developers:
- more passion for finding a solution;
- no knowledge transfer is required;
- possibly lower personal costs;
- no risk of ‘nothing to do’ - daily operations;
- reduced risk of issues with buy-in;
- same people experiencing bugs are resolving them (fewer communication lines means less miscommunication); and
- IT can focus on bigger problems.
With all of these perceived advantages, the idea would catch on. These technologies included so-called fourth-generation programming languages (4GL), computer-assisted software engineering (CASE) tools, and early rapid application development (RAD) tools.
And yet, professional software developers are in no real danger of being replaced by citizen developers in the near term.
A future generation of citizen developers has been announced with alarming repetition. So, why has an idea this good struggled to catch on? There are 5 reasons.
- Many organisations see little value in replacing their experienced developers with an unproven platform to be used by inexperienced personal.
- Time constraints. If your staff’s daily operations are valuable, why would you ask them to allocate time to doing other tasks?
- Many platforms promised more than they could deliver. While 4GL and visual programming technologies offered a glimpse of a better world for IT and end users, a glimpse is a glimpse.
- Failure to keep up with best practice. Version control, testing, deployment, documentation, and other best practices were often unsupported, and needed to be completed manually.
- The rise of Software-as-a-Service (SaaS) has greatly diminished the need for organisation to develop custom software. The average organisation uses around SaaS apps.
The rise of low-code
The issue has (mostly) never been with the idea of low-code, but more with the timing. Mostly platform maturity, but also business landscape.
Momentum for app building tools has picked up again with a rise of so-called low-code platforms.
The answer is in the platform. Rather than offering an interface that simply obscures the actual code generating an app, the new generation of low-code tools are self-contained (yet extensible) platforms that enable people to build within an environment that’s already hospitable to all the unseen components of the app. That eliminates the need to update the platforms or apps due to changes in the code base or infrastructure. In fact, most modern low-code platforms are delivered via the web, meaning users don’t have to worry about any updates at all.
The cloud platform approach also empowers these tools to provide far more security and reliability than ever before — making it much easier for organizations to deploy with the confidence that they have the right controls in place to meet their security and compliance standards. If the platform itself offers high-level security and compliance controls, the path to deploying platform apps securely is much shorter.
Finally, the user base for these platforms has matured in the past decade. This has given rise to best practices, a thriving ecosystem of partners and app builders, and a better understanding overall of the capabilities of each platform.
Overall, we’ve gone from so-called fourth-generation programming languages (4GL), computer-assisted software engineering (CASE) tools, and early rapid application development (RAD) tools to Business Process Management (BPM) platforms, and now low-code and no-code.
At this stage, it seems like low-code and no-code can coexist. As low-code helps developers be more productive and no-code helps non-developers become developers. Both of these have a time and place.
However, so far, low-code platforms appear to be delivering much greater value to businesses.
James Martin dreamed of developing software without software developers. Ironically, app building tools are mostly empowering developers to spend less writing code and more time creating applications.
Written by Eban Escott
Founder of Codebots
Dr Eban Escott received his Doctorate from UQ (2013) in Model-Driven Engineering and his Masters from QUT (2004) in Artificial Intelligence. He is an advocate of using models as first class artefacts in software engineering and creating not just technologies, but methodologies that enhance the quality of life for software engineers.
