If you’re involved in the IT sector, you’re likely acquainted with the term “low code”. Recently, I’ve observed my boss at zen8labs frequently bringing up low code, suggesting he’s quite interested in the topic. This raised my curiosity, what is it about low code that has captured his attention? A quick browse through websites and forums reveals a variety of explanations for what it entails. Let’s inspect some of the interesting definitions I found on the internet: 

• Low code is a software development approach that relies on visual methodology. It uses various tools to construct automated processes without the need to write extensive code (or, in some cases, without writing any code at all – referred to as “no code”). 
   
• Basic low-code platforms come with pre-built components similar to Lego pieces. Users simply select the pieces they want, then use a drag-and-drop feature to arrange them. Afterward, they can configure the parameters and connect these components to create a specific solution. 
   
• A low-code platform is a technological approach that allows users to create complex applications without needing extensive programming knowledge. Instead of writing code from scratch, users simply drag and drop components on a graphical interface and configure them to build applications. 
   
• A low-code platform offers a quicker and easier approach to application development. Thereby reducing development time and costs. It also addresses the issue of overreliance on professional developers, allowing businesses and organizations to create applications more quickly and skillfully. 

Just by skimming through this kind of information, you can see that low code has a lot of useful aspects. 

What are the benefits that low code?  

• Write less code, achieve greater results, and achieve outcomes faster. 
• You can use a drag-and-drop functionality instead of tediously writing each line of code. 
• No need for extensive programming knowledge to create a product. 
• Requires less effort and resources, with reusable components that help businesses minimize costs. 
• To quickly implement ideas, accelerating time-to-market which provides a competitive edge for businesses. 

These benefits can be summed up into two main points: faster speed and less effort. But is that really the case? 

To get answers to all these questions, our boss set us an assignment: use a low-code platform to create a product in a short period of time. Specifically, he suggested using the Odoo framework to build an ERP (Enterprise Resource Planning) product for a network of various clinics. Let’s break down this challenge a bit and identify some key points to consider: 

• Must use a low-code platform 
• Must create an ERP product 
• The product must have abstraction capabilities 

Based on the strengths mentioned earlier, we can assess that among the three “musts”, the first two are entirely feasible.

What is Odoo?

In case you didn’t know, Odoo is a robust framework for an ERP. Many businesses use Odoo software to manage their organizations, such as overseeing materials and inventory, human resources, finance, sales, accounting et cetera. If you’d prefer to drag-and-drop features instead of writing code, Odoo supports this through its studio, which allows you to freely drag and drop almost anything into your project, whether it’s a view or a model. This flexibility means you can quickly create a product just by using drag-and-drop.

If you need to launch a new feature without deep domain knowledge, Odoo has you covered. The Odoo development team has analyzed a wealth of data from various sources and types, providing a broad perspective, so most of the features offered are ready to use without much need for custom adjustments. 

The final must

It seems this task shouldn’t be too challenging, so what’s the problem? The issue lies with the last must: it MUST be abstract. How do you achieve abstraction? Our project team combed through over 10,772,688 lines of code to find the answer. You might not believe it, and you’d be right to think we couldn’t possibly read that many lines of code to get the job done – we don’t have enough time or patience.

However, I can confidently say that we read and analyzed about 1/50 of that number to find a solution. The rest? We’re still reading them every day. Up to this point, you might notice a paradox: why, if we’re using a low-code platform, do we need to read and understand such a high number of lines of code? It contradicts the supposed benefits of “less effort and less time” that I mentioned earlier. To put it more poetically, we’re going against the very philosophy of low code. Not only are we putting in more effort, but we’re also taking more time. We’re investing more resources into a platform known for being “low-resource” and “low-time”.

This seems problematic, is it possible that we’re approaching a low-code platform incorrectly? The answer is no; our approach is consistent with our role as developers. To be clear, low code is intended for platform users, while developers are responsible for building and maintaining the platform itself. From a different perspective, if you only use a low-code platform, if you limit yourself to just using the platform, you are just a consumer of the product; you can’t claim to be its creator. Returning to the complex task mentioned earlier, let’s break down the requirement for abstraction into more concrete tasks:

• Build a solid, coherent architecture that supports abstraction requirements 
• Orient business requirement analysis toward abstraction 
• Implement modules in line with the framework’s principles 

Building an architecture, especially when abstraction is required, is a significant consideration when using a low-code platform. You can’t do just anything with a low-code platform like you might with traditional platforms. Low code, particularly in this case with Odoo, doesn’t function exactly as you would like it to. You need in-depth research into the low-code platform to create an architecture that both meets the abstraction requirements and aligns with the existing framework architecture and the underlying philosophy the developers had in mind. The design must allow for new features or modules to support low code use for end users. 

We discovered something that’s both fantastic and problematic in many cases: the open nature of the modules in this framework. You can freely customize the modules provided by the framework, but once you change business requirements, it becomes challenging to achieve the desired functionality. In most cases, you have two options: either use the module entirely as provided by the framework with minimal customization or build a new module from scratch according to your business requirements. Deciding between these two approaches can be difficult, and it often depends on specific criteria in each situation. You find yourself in a dilemma where low code offers quick results and a fairly complete product in terms of features but doesn’t fully meet your initial business requirements.

Sometimes the difference between the two options is only about 10%, and you have to choose one or the other. However, in most cases, a low-code-based software development team has to comply with the platform’s design philosophy and sacrifice some flexibility. This means that, to work with low code, the development team needs to spend more time on requirement analysis and planning. This raises the question: is low code really low code? If you consider the semantic aspect, it is still technically low code because you are writing less code, just not “low analysis”. 

Developing the modules

After choosing the implementation approach, we worked together to develop the modules. There was a time when the Business Analyst (BA) asked us to add some attributes to a model and display them on the view. Some team members decided to use the built-in feature that Odoo provides to quickly complete the task, which involves adding features directly through the user interface with just a few clicks, drag-and-drop, and entering some information – no coding required. Great! It took us only five minutes to complete a task that would typically take one to two hours on other platforms. This approach saved the team significant time and effort. However, having read 1/50 of the total codebase, some of us couldn’t accept this proposal. We understood that this “quick-fix” approach wasn’t suitable for this case. The ability to quickly drag and drop views, models, etc., directly on the user interface is a result of Odoo’s development team building a robust and highly open data structure. They found a way to store all interface changes, whether raw data or structured data, in the database in a smart way. This storage method ensures that every time you change any structure, attribute, or view by drag-and-drop, those changes are recorded in the database.

If you change the database, everything disappears, and you’d need to redo the setup you had with the old database. This is why users can “build a fully functional website just by dragging and dropping” without needing to know how to code. This feature, common to most low-code platforms, requires an exceptionally strong plan for building the codebase. Who builds the base for these low-code platforms? It’s certainly not the users who drag and drop; it’s the software developers who make this happen. So, is low code really beneficial if you’re a software developer? If every software developer only needed to type a few lines of code and drag-and-drop to create a product, who would create amazing low-code platforms like Odoo? So, who should use low code, and who can use low code? 

What perspective should a developer have on using low code? 

Anyone can use a low code platform to create a product, even if you don’t know how to code. This statement is true but incomplete. If your only goal is to create a product, then the statement holds entirely true. However, if you aim to use a low-code platform to create a product in a smart way, you need a deeper understanding of the platform. Besides reading and understanding the platform’s built-in features, you also need to grasp its codebase. Soldiers need rigorous training before going into battle, and similarly, reading, researching, and gaining an in-depth understanding of the platform are critical preparations for tackling a project that promises “less resource usage, less effort, faster time to market, higher completeness, and greater feature availability”. 

We can see the issue clearly: to achieve low code, you first need “high research”. I’m not sure if this fully answers the initial question I posed in the title, but perhaps this is one of the reasons why my boss “likes” low code. Or maybe not. 

Useful cases for using low code 

One of the main points I want to discuss in this article is: when is it appropriate to choose building a low-code application instead of a traditional application? 

• My boss needed to create a proposal for a new project. Although his documentation was thorough and comprehensive, it wasn’t much different from what other service providers were offering. So, he decided to create a demo product to make the proposal more compelling to clients. However, the time to prepare the proposal was limited, and building a demo product within the tight timeframe seemed unlikely. He opted for a low-code platform to build the product. In the end, I’m not sure how the clients responded to his proposal, but he gained new knowledge about a low-code platform, and we gained a trusted resource to consult when we faced low-code challenges. This illustrates that low code is very useful when you need to build a demo application, experiment with an idea, or create a prototype in a short period.

• Let’s take my boss again as an example. If he hadn’t chosen low code to create the demo, he would have had to build a traditional product and face daily and weekly overtime. But by choosing low code, he only needed to put in about a third of the effort compared to the traditional method (assuming he’s well-versed in the platform he chose). This way, he could spend weekends taking his kids out, spending time with his family, and still deliver the demo product as expected. Clearly, when you have limited resources to dedicate to a project, using low code can be an excellent option. In this case, it’s very useful because it not only reduces the resource requirements but also lowers costs.

• For internal applications or business operation support tools that don’t require too many complex features, low code can also be a highly effective choice.

• If users don’t have much technical knowledge, they can leverage the visual aspects of low-code platforms to create simple products.

Limitations of low code

Of course, every method has its pros and cons. Let’s explore some of the limitations of low code to understand it better: 

• The first limitation you’ll notice with low code is that it can be quite challenging to build a relatively complex feature on a low-code platform. The more customization you need, the less suitable low code becomes. Let me give you a specific example to illustrate this. When our team needed to add several non-product items to an invoice, we struggled to find a way to do it using Odoo and its existing invoice module. In the end, we opted to turn all those items into products. If you use a traditional platform, this wouldn’t be difficult – you’d have various ways to implement your idea. But with a low-code platform, everything is quite different from conventional thinking. We could only choose between a few options and spent many discussions to finalize an approach that both satisfied the customer and adhered to the framework’s principles. Although, in terms of concept, the final solution we chose didn’t please everyone, it was the best we could do with this platform. From the outside, you might see us occasionally suggesting some seemingly foolish solutions, but if you were in our shoes, you’d understand that it’s a reasonable approach. 

• The second limitation: you can’t control everything that the platform provides. The platform offers many cool features, but you can only control the code you create. Even if you know which function or line of code contains a specific logic, it can be very difficult, if not impossible, to override that logic. Because of this, we had to discard many requirements from the business analysis team because we couldn’t implement them. This also makes bug fixing or performance optimization much more challenging. 

• Another challenge you might face is when you need to integrate other services from third parties. In most low-code platforms, you’re locked into the ecosystem it provides, making it challenging to integrate new technology from outside sources. Additionally, you might also encounter restrictions when trying to offload the platform’s services to other external services. 

• One of the key considerations is that the architecture of a low-code application is typically constrained by the platform’s design and capabilities. Consequently, the customization and flexibility of applications built on these platforms are often limited. 

Conclusion 

Low code reduces the burden on information technology product development teams, allowing them to focus on projects with greater strategic importance. The ease of maintaining and updating low-code applications also contributes to increased efficiency and lower long-term costs. However, low code is not a one-size-fits-all solution. It has limitations in terms of customization, performance, and scalability, and should be used cautiously, with a clear understanding of its boundaries to avoid unexpected risks. Perhaps my boss “likes” low code because he’s keen on fostering innovation, boosting productivity, and optimizing resources. However, to succeed with low code, both my boss and the team must approach it with careful consideration, ensuring it’s used for the right purpose and at the right time. 

If you’re reading these lines, thank you for staying with me. So, to wrap up, why do you think your boss “likes” low code? 

For more interesting topics, check out our zen8labs blog! 

Tuyet Le, Software Engineer