No-code solutions aim to empower non-technical people to create their own software solutions with zero need to code anything at all. The term no-code is sometimes used as a slight variation of low-code. In fact, we can often see tools defining themselves as no-code/low-code tools. All big companies are buying into it.

I discussed before the difference between the low-code and no-concepts. Long story short, no-code really means no code at all, which limits the variety of applications you can build. We are basically looking at template-based frameworks or the creation of workflows mixing predefined connectors to external applications where the designers, at most, decide when and how certain actions should be triggered. This is a reasonable trade-off if you don’t want/have the time to learn to code. And the number of different applications you could create is still huge with an increasing number of no-code solutions ready to help, no matter the type of applications you have in mind. But no-code doesn’t mean that you’ll be able to create your dreamed application in no time.

I want to highlight two subcategories of no-code applications: no-learn and no-work development tools. The following image describes the relationship between each category.

No-Learn software development

No-learn development tools correspond to the set of no-code frameworks that let the users employ their own tools to define the software to be built. Instead of the user having to learn to use the no-code tool and the (graphical) language behind it, the no-code tool is able to read and import the software definition from Word, Excel or whatever other tool users in that domain typically use.

An example would be our Excel to chatbot service. Instead of forcing users to learn a new interface and language to define chatbots, we offer them an Excel template that lets them define bots in a tool they already know. No matter how great is our no-code tool, if it’s a new tool the user will need to invest time learning it. Better to eliminate this barrier to entry.

A no-learn tool can still have the same expressiveness as a general no-code one. We’re not limiting what users can do with it, just changing the language in which that no-code project will be defined.

Low-modeling / No-Work software development

No-work is an extreme case of no-code development where the user does nothing. Users do not code but neither do they define the application to be built. Not within the no-code tool interface, nor with their own tool (no-learn category above). They do nothing. Instead, the no-code tool takes whatever information is already available in the company (in documents, files or databases) to automatically derive a software application from them based on internal models inferred from the analysis of that information. Similar to low-code where code is derived from something else (models in that case), in low-modeling, models are also derived, in this case from (un)structured data. Then you can modify the models or, in the more extreme case, directly use them to generate the final software system, in a pure no-work approach.

It’s not magic, no software is built from thin air. It’s data-driven. It leverages that every company is full of data and that data has always some structure to guess the software needed to create software that does something useful from that data.

Continuing with our chatbot definition example. In a no-work setting, we would not even ask the user to fill our Excel template to specify the bot behaviour, we would just take its FAQ website, existing Excel file (e.g. with some list of questions they prepared to homogenize their client support team) or list of products in a database and generate the chatbot from there. In our interviews with potential chatbot clients, they often tell us a variation of the sentence “we already have an Excel file we use internally, we just want to give you that and get a bot that is able to answer the questions in our file”.

This completely eliminates all barriers to entry. As a trade-off, no-work approaches do restrict even more the diversity of applications to be built, as the no-code tool needs to largely depend on convention over configuration strategies in order to be able to derive a valid application from the client’s input files.

Still, this approach is less radical than it seems. Just think about all the CRUD generators (including at the modeling level to augment UML class diagrams with relevant operations) available on any modern programming framework. Any of them can connect to a relational database and immediately generate all the forms required to access and manipulate the database data.

No-code categories are not exclusive

Each of the categories above targets a different type of user/scenario. Depending on how much the user wants to learn/work, you can offer him a specific type of tool, each one with its trade-offs.

But this doesn’t mean your low-modeling or no-code tool needs to stick to one specific category. As we do in Xatkit, you can offer different interfaces/importers on top of the same engine. You can even offer a low-code version for advanced users willing to use your tool’s API to complement the result of the no-code approach. Or use a no-work data-driven model generation approach to generate an initial set of models that you’ll then refine and extend to create more complex software.

Featured image by Kate Stone Matheson on Unsplash