Word cloud generated with WorldClouds.com

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.

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.

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.

• “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?
• 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?
• 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?
• Flexibility: what can we do on these platforms? How far can we take our application?
• 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!
• Best practices: if the prototype application becomes a product, can best practices (peer review, testing, …) be enforced?

Hands-On: Planned vs Realized

The plan was, over 3–4 months, to:

1. Take two platforms.
2. Hire an intern to help us. The main team had a full-time intern, a part-time developer, two part-time senior developers/architects. Occasionally, a designer.
3. Have some online/in-person training to grasp the basics/paradigms.
4. Pick an existing web application, developed by more or less the same team using traditional coding. The selected application had some graphs in the frontend and a .NET backend for data mangling.
5. Recreate parts of the application, piece by piece, in Low-code, with both platforms.

Point 1 to 4 went almost smoothly. Both companies offered us trainings of some kind, more or less customized and very interesting. The only hiccup was during one training, in which we didn’t manage to get and use a bearer token from a third-party API. But more of that later.

Let’s zoom-in into point 5:

1. Start small, let’s make a Low-Code frontend that can log-in into the existing backend (learn and evaluate integration, use OAuth2 to get a token).
2. Great, we have a token. Let’s use it now to call some endpoints, and get some more-or-less nested data structure (more complex integration use-cases).
3. Let’s put the data in a couple of boxes and charts (structure parsing, UI design, and implementation).
4. Can we get some help from the designers in the company? Would they customize the application themselves? (Ease of design)
5. Let’s stop using external backend. Low-Code platforms offer their backend and databases. Let’s use them by moving part of the .NET logic into Low-Code (feel the platforms end-to-end).

For each step, we envisioned to write some tests.

It was not that smooth. We expected more than we found, and the enthusiasm quickly descended.

Let’s dive into each step:

1. OAuth2 has been around for a while, and it’s the de-facto standard authentication mechanism. How can it be that there is no drag-and-drop or integrated mechanism to make it work? We had to implement the REST calls, and fight our way through workarounds to keep the token persisted between calls.
2. Calling REST endpoints is fairly easy. However, it feels like it’s not the way these platforms expect you to work. Both platforms had limitations on how you could use the data obtained from a REST call, versus the data you get from their databases. Strong limitations: for example, weird workarounds were required to put these entities in a page (or in a dropdown), one of them required quite some wordy importing and model-definition to be able to use REST, the other could import Swagger descriptions but could not handle reusing the same model in multiple endpoints or recursive models.
3. Mangling with data using graphical description of the logic was a nightmare. In the beginning, it was very easy. The moment the mangling started to be slightly more complex (e.g. pick N arrays, sort them, use some logic to combine them into a new set of arrays), the amount of operations needed exploded. Building the graphs was not easy, either: styling required css and fighting with the data format to get it properly represented, one platform had very limited options to put data not persisted in a graph, and we had to embed a JS library to do so.
4. We showed a carefully-designed demo to our designers. The demo was somewhat easy, we did not want to scare any designer, and we refrained from using scary words like REST. However, that didn’t help. We got comments like “I need to think as a developer, not as a designer, to use this platform”, “Do I need to do this like that? In Sketch I can do just like this”, “Look at this mock I developed ten minutes ago”. I was surprised to hear from one of the two companies that their designers don’t use their platform, either.
5. Given point 3, we decided not to move forward. We resized a lot what we wanted to achieve, from re-implementing the .NET logic, to making a comment box where users could post their comments. This was surprisingly easy. Once a comment was defined (as a class with an author, some text, and a creation date), dragging and dropping it into a page was enough to realize the whole set of CRUD operations we needed.
6. Both platforms offered very similar testing frameworks, mostly oriented to functional testing. We tried a unit testing-oriented approach, but it did not fit. Mocking required to re-develop custom mock endpoints, or use the live databases. The code needed to be polluted with testing checks (e.g. if isTest use this endpoint) to check at runtime what to do. About good software practices, no peer review was possible.

In almost all steps we had to write something on the forums, and for a couple of issues, reach out for technical support. The communities were not disappointing at all, with a lot of peers willing to help. The technical support was helpful. However, the support itself had some issues with requests that, coming from a coding background, seemed quite simple.

Hands-On: What we could have done better

The hands-on was a difficult part of the journey. It started with a lot of enthusiasm and ended with some disappointment. Looking back, there are choices we made that have had a direct impact on the result:

• Stubbornness. We had discussions with the two vendors behind the platforms, and they suggested a different approach, with more guidance from their side. We had our reasons, but maybe our approach doesn’t fit with the technology we were looking at.
• Perspective. We set the bar quite high, expecting a higher maturity of the platforms. We wanted almost the flexibility that we can get from coding and ease of use that can allow designers to use the platform unsupervised. We had no interest in simple Excel/Access-like applications, or in Enterprise IT applications.
• Team organization. Having an intern on the driver seat and developers as support may have impacted the result. While the fresh perspective of an intern allows for a more unbiased opinion, seasoned developers may grasp new technologies easier. However, each of us played for its own entertainment with the platforms, getting to more or less the same outcome.
• Timing. Were around 4 months enough to climb the learning curve?

The end, and the Next chapter

After one year of exploration, we had to wrap up, make a decision, and look forward to the next chapter.
Low-Code has great hype behind it, and the development is going at an impressive speed. Most of the vendors we have been in touch with had a very customer-centric approach, trying to understand what could work for us, and how they could improve their platforms.
The limitations we encountered prevented us from jumping on this trend. We are developers that are looking for tools to quickly build domain-specific prototypes that can scale to full-fledged complex applications, not enterprise IT applications. A perfect integration with SAP or ready-to-use templates to manage inventory do not necessary help us. At the current stage, the feeling is that the platforms are trying to cover a broad customer segment, ranging from Almost-Citizen-Developers to Almost-Developers, and we are not in that range.

We see how fast it can be to develop a full-fledged small application (no need to find a cloud provider, to host the application, the database, a way to deploy locally, write the boilerplate to bootstrap the application…), but the approach does not scale with the complexity of the applications. The Low-Code grows more and more difficult to use and maintain the more complex the application becomes.
We see Low-Code as a technology with great potential, and we will keep a close eye on it, with the hope to hop on it in the future.

Acknowledgments

Thanks to Bram H., Rian W., Lambert vdW. for guiding the exploration, and to Daniil P. for joining our team.
Thanks to all the people that helped us during the process.

Original article on Medium: