Is Low-Code Good Enough for Enterprise Software Development? Part I

What is low code? It’s easy to get the value it brings from its name. Basically, it takes away the coding part from the app delivery process.

Take Bubble for example. Its drag-and-drop editor allows building fully functional apps for desktop and mobile users. Below you see how the logic of your product is designed.

And this is the UI layer for you to decide how it all comes to life before the user’s eyes.

Bubble even takes away the hosting troubles from you, providing server maintenance, infrastructure and operations services.

This low-code platform offers you to put together all the features you need in one place and have a complete web service ready to grow your business upon it. Admittedly, the idea works. For many, this is what disruption looks like. I’m not an exception. How come reviews like these show up?

To get to the roots of the problem, we need a little bit more of the context. What I suggest is that you should see how a real-life insurance project combines low code and conventional coding and draw your own conclusions.

The whole project – let it be the Alfa application – revolves around reinsurance contract entries.

Our task was to:

a) make life easier for people who work with these contracts = automate the process.

b) make sure that all fields, values, data types in the contracts uploaded via the Alfa application match the data types that exist in the Omega application.

Finally, the task was to be done using a low code solution of the client’s choice. So far, it goes all smooth like in a beautiful song, isn't it?

The answer is blatant – because we are developing software for internal use. Here low code solutions allow you to quickly, albeit with some limitations, implement a missing business functionality. For this project, we develop the backend and APIs in .NET, and use Outsystems for the frontend part of the jobs. The ready-to-go application looks – well – acceptable, but most importantly, it provides the functionality that the business needs. For more clarity, let's go back to the harsh reality of corporate routine.

To automate such a process, low code is an ideal choice. Why? Because it will do the job quickly, provide the functionality required, and the business will get rid of their pain in the neck in almost no time.

Perhaps the resulting application won’t be the fastest application ever. Yes, definitely it won’t be a second Telegram. Telegram is recognized for its speed. However, it is written in C++, the language which many engineers would consider a curse to work with, but it is C++ that gives Telegram this notorious speed. Yet in the case of Telegram we’re talking about the applications that hit the B2C market and therefore need superior user experience. As for corporate applications, it’s different.

With low code, your UI/UX customization options are limited. Undoubtedly, THERE ARE customization options, but, say, when you hover over the button, it won’t change the color as you expected. Or that cool animation you saw in the competitor’s app – the low code solutions most certainly won’t allow it either. But let's all remind ourselves why we are all here – we need to automate the document flow process in the accounting department, and this is what the low code platform will do just fine. How is this going to happen? Let’s see.

Simply ask your Business Analyst to sketch out the front-end layout of the application in Balsamiq. This will do enough for the frontend developer to see how the document flow is going to happen. Then an Alex or Michael from Symfa comes and implements the frontend in a day or two using Outsystems. If we had to develop this on a framework, the layout alone – with no transitions or integrations – would take a decent amount of time. In the Alfa application, we have about 15 unique screens. With Outsystems, Alex would do them in 2-3 working days. As for AngularJS, it would take about two weeks, or even more with all the attention that CSS, HTML, and JavaScript require. Two weeks just to put it all together. It won't even be clickable.

Again, it all goes too well. Less romance now, but it is still smooth and inspiring, right? Well, reality is often disappointing. So, let’s talk about the limitations that out-of-the-box low code solutions impose.

The reasons why you may NOT want to use it abound. Let’s touch upon those three that we faced during this exact project.

1. The effectiveness of the resulting solution will depend on your goal. Say, Outsystems won’t give you a great product to sell.

I want a web app that the user will hit and say – oh, that’s nice! Nope, not with a low code.

How about a functionality with a great look and feel that they write today in JavaScript, with all kinds of animations, swooping transitions?.. Nuh-uh. This is not about low code either. 

Low code is about functionality. Period.

2. Although Outsystems can be very well used to build backend, for Alfa we use .NET for the backend jobs. We have our own reasons for that – Outsystems isn’t that flexible to meet all the demands of the complex logic of an insurance client. Second, .NET is the programming environment of choice for our corporate client, so it is oftentimes easier and quicker to implement that sort of functionality using good old .NET.

3. With low code solutions, teamwork can be a problem. In particular, with Outsystems version control is a bit of a pain in the neck. Whenever one person updates the build, the other cannot do a thing. No big deal, good project communication will sort the issue. Just keep that one in mind.

As you can see, it isn’t all roses, but not so bad either. Which leads us to the logical conclusion.

Not so fast.

Will lowcode/nocode replace traditional coding?

Not today.

Low code solutions ain’t rocket science. Not something that any full-stack developer with Angular and .NET. behind their back cannot master in a few weeks. For example, for this client, our full-stack developers learned to work with Outsystems (it wasn’t vice versa – developers with Outsystems learned full-stack development). 

Slower, please. What you imply is that it is impossible to take a random person and teach them how to make ugly, but super functional corporate applications in two weeks? That's right. 

We all still will need engineers with full-stack qualifications for some time in the future. Suppose you can put up with some limitations in the interface part. Go for low code then. As far as the backend goes, you cannot compromise on the logic. A full-fledged framework gives us this freedom of action to implement precisely what we want the way we want it. Thus, low code is a nice addition to the CV for a full-stack developer nowadays, but this is optional, quite easily acquired knowledge. I’d see it more as a nice-to-have rather than a must-have. For the Alfa application, one person did the backend and almost all the front-end part. The application isn’t that small, but here’s the punchline – the developer isn’t a muggle either. He is a full-stack developer with five years of active programming experience who mastered Outsystems in three weeks.

When I pick up a team for a project, I don't need everyone on the team to learn Outsystems. I need one person who knows how to work with it to implement frontend. For the rest of the team, I will focus on the .NET qualifications. These should be strong .NET guys, because the magic will mostly happen in the logic part. 

• So, for a team of three, in case we went for the framework development, that would be three people doing both back-end and front-end. 
• With low code, I’ll have only two engineers doing the back-end and one on the front-end, which already saves the customer time and budget for the project.

Ah, I almost forgot one little thing. Whenever we opt for framework development, we need a UI/UX designer. Again, this may sound disappointing to you, but if you rely on an engineer to do the UI/UX part, you’ll regret it in 99,99% cases. That’s why for the projects that you build using conventional frameworks, you’ll need a designer to make the layout, solicit and implement your feedback in order to hand over the ready layouts for the developers to bring them to life.

In Outsystems, there is a set of ready-made elements with a pretty typical look and feel, on top of which our customer applies their corporate theme. That is, if you have several corporate applications developed on a low code solution, they will all have the same header, buttons, background color, fonts, etc. The designer works on the theme (again we cannot get rid of them), then the theme connects to the low code platform and it appears in all the applications that you build within the company. It’s functional. It saves you time. It’s what I call instant value.

This is it for Part I of our story. I won’t be away for too long, so stay tuned for the next part of the story.

Next week I’m going to discuss

• Why low-code isn’t good for everyone
• A quick recap of traditional vs low-code tools
• The results of our project: did Outsystems meet our expectations and how it contributed to the project success.

See you in the same place.