As software development techniques and tools advance, we progressively move towards low code and no code approaches. This makes sense because low code and no code approaches can drastically reduce development costs and time and therefore make many more software applications economically viable to create.
An even bigger benefit of these approaches, especially no code, is that business users who are domain experts can create and refine applications without the friction of having to explain their ideas to others. This dramatically reduces the time to deliver a high quality product to market.
It is logical that software development moves towards no code. Excel has been the world’s best example of a no code (in general) success story. Many applications can be built by business users. It’s hard to exaggerate the importance of Excel in delivering a productivity boost to the world.
The low code future, of course, is not about single application development frameworks, but about an ecosystem of easy to consume APIs. Zapier is an example of how these APIs can be consumed with zero coding.
Of course, no code can also introduce problems, in that no code solutions can be less maintainable and less secure than higher code solutions. Excel is a case in point.
It should also be noted that low code does not mean that people off the street will be able to create useful applications on day one. A low code environment that allows for the creation of relatively sophisticated applications certainly requires that the user of these applications have a good grasp of the concepts and the features of the tool itself. It is like any sophisticated software tool.
Even if the no code tools reduces the complexity of building certain types of functionality versus building these features with code, there is no way around the fact that achieving complex functionality will entail some degree of complexity even in the no code tool. A clear example of this is game development engines such as Unreal Engine where low level coding concepts (such as while and for loops) are represented visually. This can be an improvement on coding directly, but requires advanced knowledge of the application and the concepts.
This means that expertise still matters, even in the no code world. Excel is again a case in point. There is a big difference between a power user and an ordinary user, not just in what they can accomplish, but in the maintainability of the end result.
On the point of maintainability, it is true that the no code solution is not necessarily less maintainable than the code based solution. In many cases the no code solution is preferable as it is much more obvious what is going on.
There is however a point where complex systems have many dependencies and contingent states, and some level of control of the development process and error handling needs to be implemented in the system, and this can be challenging to do in no code tools.
It can also be the case that the limitations of a no code tool make it much more complicated to create a certain feature than would be the case if the feature was coded by an expert. It becomes necessary to hack a feature in a no code tool which would be relatively easy to build in code. The problem is that the level of abstraction that the no code tool implements, makes some use cases hard to build. There are many examples of this from the world of Excel.
In short, the use case will determine whether it is better to use a low code, no code or a fully coded solution. Like everything in life, there is some judgement required as to what the best approach might be for a given use case, but there is no doubt that the trend in software development tools is towards low or no code.
The advance of low code solutions doesn’t necessarily mean that there will be less work for software developers, but it does mean that software developers will need to use a combination of code and low code / no code platforms to achieve optimal efficiency.
Economically it means that it will be economically feasible to develop many more applications and therefore it is likely that developers will be occupied with specialized work on many more projects and on building more consumable APIs for the world at large.
In summary, we believe there will always be a role for some element of coding and therefore the end goal will be low code rather than no code. A low code environment is designed to allow developers to easily add custom functionality that complements functionality built on the same framework with no code tools. This is the best of all worlds where professional business users can develop a large part of the software and where developers can impose professional software development practices and provide custom functionality on the software.
The low code and no code trends also apply to chatbot development technology. There are already many no code platforms, although the functionality offered in this space is relatively limited.
No code platforms already make a lot of sense for simple chatbot use cases, particularly in the marketing realm, where the bot is mainly providing information and user interaction is limited.
There is a tendency in the chatbot space for people to underestimate the need for custom development and therefore believe that it should be possible to create no-code development tools on which complex bots can be built by business users, without a material sacrifice of customer experience.
It is human nature to underestimate the task at hand. Almost every plan we make is a simplification of reality. When we try to carry out the tasks involved in undertaking the plan, things crop up that we didn’t anticipate, either from lack of foresight or because they were totally unpredictable.
Once you begin working on the software, no matter how good the specification, changes to the use case or the way the code was written are inevitable as new facts are brought to light through the development process.
It is often the case that the chatbot needs some complex functionality that requires programmatic logic or a custom graphical interfaces. For example, the chatbot may need to track scores or interactions with the user, it may need to interact with a web page, it may need to offer a simple screen for the user to enter their trivia data for a custom trivia bot. The chatbot may need to manage and reset contexts depending on where the user is in a flow. None of this is necessarily obvious at the start, especially for people who are not experienced in building chatbots, but these things make a big difference to the user experience.
We have spoken about Excel extensively in this blog as an example of a highly productive no code environment, however, in reality Excel is a low code environment with extensive features to allow developers to write code or integrate with code. Regardless of the number of templates and features included in the software, there will always be the need for customization to satisfy certain use cases.
Ultimately the trade-offs are between the overlapping factors of efficiency of development and the quality of the user experience and the return on investment of the project.
The challenge for no code frameworks is to deliver everything needed to create a quality user experience. The challenge is that the 10% that is hard to build on the no code platform might make all the difference to the end user. In the world of chatbots, the illusion that it may be possible to build everything in a no code way is powerful.
In our view the trend will always be to create better low code, not no code, chatbot development platforms where the scope of functionality that business users can create by themselves will always continue to expand. In this blog, we have outlined the benefits in creativity and economics that come from allowing business users to create software by themselves and therefore this it is critical to make chatbot development frameworks as powerful as possible for business users.
It is also the case that certain aspects of all software development, including building chatbots, need to be provided by developers through code and this needs to be as easy as possible to do for the developers. Low code will never be totally displaced by no code, however they will always need to become better and better at serving their two main customers, professional business users and software developers.
Disclaimer: We encourage our blog authors to give their personal opinions. The opinions expressed in this blog are therefore those of the authors. They do not necessarily reflect the opinions or views of Botpress as a company.