A Tale of a Journey Across Low-Code
By: Massimo Tumolo
Tags: Innovation, Software Development, Development, Technology, Productivity

Last year I had just landed my first job as Software Developer at Signify (the former Philips Lighting) and, after a few weeks, a colleague asked me if I wanted to go to a No-Code conference with him. “A conference with everything paid? Nice!” I ran to my laptop and started my desk-research on what Low-Code was. It kind of reminded me of the MIT App Inventor, but wider, more feature-complete. It triggered my curiosity: “Is this the future of the job?”. I did not expect that I was about to embark on a one-year-long exploration, that would have exposed me to external vendors, to other departments, and could have potentially changed the way we develop in our company.

In this article, I am going to describe the exploration process we followed, what were our expectations and learnings, and what we see looking forward.

How and Why it started

Low Code Platforms: Software that provides an environment to create end-to-end web or mobile applications and lift infrastructure through graphical user interfaces and (possibly) traditional programming.

In the continuous strive to improve our process and technology competencies, to increase our productivity and reduce the time to get from an idea to a prototype, some colleagues started looking into the Low-Code world. The choice for this technology came from past experiences in different companies in which the technology was successfully adopted, and its impressive presence at the Gartner’s Conference in 2018.

Gartner Magic Quadrant for Enterprise High-Productivity Application Platform as a Service, 2019, from DZone

There were two main desires: the ability to quickly build prototypes that could be easily integrated with the existing backend infrastructures, and the ability to co-create with UX/UI designers and let them use the tools to co-create with the customers.

Desk research depicts Low-Code in conflicting ways, from the future of the development to a disaster. A lot depends on the context, and on how these tools fit in the company culture.

From many to few

There are many Low-Code platforms in the market. Trying them all would take just too much time.

Low-Code selection process

We started by walking around some conferences, talking with employees, partners, customers. At first, we were impressed: big audiences, from half a thousand people to a few thousands, a big number of applications running on the platforms, speed and agility repeated in almost every keynote. Later, we realized that there was something missing: many demos and claims were quite generic, we left each conference without a real feeling of what is possible and how. Something more was needed.

We picked some of the vendors from the Quadrant and got in touch with them. We asked for some technical information (Does your platform support REST calls? And OAuth2?) and a short face-to-face demo. Not the nicest process, but it already started highlighting some differences:

Native Low(No)-Code platforms (created to do that and that only) and platforms that are evolving towards Low-Code : the former with greater flexibility and complexity, the latter with some flexibility on top of their earlier scope. We did not have an application scope in mind, as we usually don’t have when we come up with a new idea. So we picked the first category.

(created to do that and that only) and platforms that are : the former with greater flexibility and complexity, the latter with some flexibility on top of their earlier scope. We did not have an application scope in mind, as we usually don’t have when we come up with a new idea. So we picked the first category. “Citizen Developer”, “Citizen Developer and Developer”, “Developer” platforms: ranging from the most graphical/blocks-oriented and less flexible, to the ones that seemed more like graphical coding. Citizen developer is a recurrent expression when looking at Low-Code, and it represents an application developer without a software background. Given the complexity we were looking for, the platforms for the “Citizen Developer and Developer” category and the “Developer” one suited better.

We chose two platforms and moved to the next step: development.

Hands-On: some premises

So, we picked two platforms: the fun could start. The attention points:

The feeling : we really wanted to feel the platforms . As a bunch of developers, we wanted to do some training, read some documentation, and bend the technology to our needs. We absolutely did not want any consultant developing for us or sitting next to us daily to help us develop. Most developers learn one/two frameworks per year, and it’s highly uncommon to have consultants help you do that. Why would we treat Low-Code differently?

: we really wanted to feel the platforms As a bunch of developers, we wanted to do some training, read some documentation, and bend the technology to our needs. We or sitting next to us daily to help us develop. Most developers learn one/two frameworks per year, and it’s highly uncommon to have consultants help you do that. Why would we treat Low-Code differently? The community : we wanted to join the community. Relying on the platform technical support is nice, but on the day-to-day development, you need a community. If I am stuck writing JS code, I know the solution is on StackOverflow. Is there a SO for Low-Code?

: we wanted to join the community. Relying on the platform technical support is nice, but on the day-to-day development, you need a community. If I am stuck writing JS code, I know the solution is on StackOverflow. The learning curve : we wanted to perceive the learning curve. If we would have adopted the platform, we would have brought on board as many colleagues as possible. How much time would that have taken?

: we wanted to perceive the learning curve. If we would have adopted the platform, we would have brought on board as many colleagues as possible. How much time would that have taken? Flexibility : what can we do on these platforms? How far can we take our application?

: what can we do on these platforms? Ease of design: can we give the platform to designers and let them put the text box in the right position instead of sending JPG designs to the developers? How cool would that be!

can we and let them put the text box in the right position instead of sending JPG designs to the developers? How cool would that be! Best practices: if the prototype application becomes a product, can best practices (peer review, testing, …) be enforced?

Hands-On: Planned vs Realized