To discuss the benefits of no-code, let’s first discuss the digression, the fundamental difference between no-code and yes-code.
Abstract granularity
Software, yes, code software, has been around for a while. As an industry, one of the things we learned is how to write software that can evolve gracefully. Unfortunately, we are not perfect, and legacy systems are still proliferating, but as a technology industry, we have learned how to build and develop software systems to cope with changing needs and constraints that span years and decades.
When we solve a problem with software for the first time, we will write some code for the constraints of the day. We don't necessarily know how the problem will change. Maybe tomorrow there will be different customers or stakeholders, or the product may be expanded to serve a related but different problem space. In order to adapt to the ever-changing environment, we need to be able to change the software without rewriting. This is the basic content of software engineering: how to change the software system. Change is the theme of the game.
In terms of change, we have become handy. We built tools like Git, and patterns like continuous integration and automatic code formatting to make it easier for us to change the code and keep it stable. Especially in the open source field, we have learned how to manipulate large software teams. We also learned to use better abstractions. Abstraction is a conceptual packaging that isolates different parts of the code base (for example, data source and user interface) so that one part can be changed while the other part remains unchanged. In general, we have begun to figure out how to adapt the DNA of the software system to the ever-changing trends of time.
For better or worse, no code seems to reject a lot of such learning. I have not seen any non-code company or product that allows source code control (I have also seen many non-code companies, but you are welcome to prove me wrong). I have not seen a no-code product that allows abstractions to be constructed naturally between the layers of a no-code workflow. For large-scale development, the preparation of codeless software is also very inadequate: our software system requires thousands of engineers-and for a team of 1,000 engineers, in a set of thousands of engineers What does the work in the code workflow look like? Two words: confusion.
Traditional software has learned abstractions and patterns. These abstractions and patterns make the software flexible and able to adapt to changes and expansions. No-code software can neither adapt to changing constraints nor the scale of development.
Despite these limitations, I still believe that no code has certain advantages in some respects. By weighing adaptability and scalability, no code tools can be made much better. So, in that case, when is no code useful?
1. Transitional and transient software
The answer is obvious, and we already have the answer before the discussion. That is transitional software, a software with a clear life cycle. If your software system has a limited, pre-defined life cycle and team, it does not need to worry about changing constraints or team development. Now, it only needs to care about how to solve the problem well.
The life cycle of many software is limited and predictable: early company product prototypes, games or applications that are part of interactive online advertising, quick sketches or solutions to fix particularly urgent problems in the product, for an event or meeting , Hiring cycle or quarterly goal tracking and development of applications... All of these are projects with a pre-defined, longest life cycle. They do not need to be continuous, evolve or change: they only need to start working now, and by giving up some of the adaptability of the software abstraction of the code, and no-code software can also benefit from rapid prototyping, which is a plus item.
I think we have seen a lot of time-limited software transitioning. In the prototype, the transition from no product to a product; the transition from brainstorming solutions to trying various design processes. Software with a limited shelf life is ideal for using code-free tools.
2. Code with high rate of change
For another type of software, long-term maintainability does not matter: code with a high rate of change.
The so-called high change rate refers to the fact that the requirements change almost every day, and the code written today will rarely exist after a month or a quarter. If the code you write today does not need to be sustained and developed, because something new will take its place tomorrow, then the speed of construction is more important than the flexibility to adapt to change.
There are a lot of codes with a high rate of change in the enterprise. For example, marketing websites and landing pages, data pipelines for analysis, e-commerce stores, marketing campaigns, payment portals-the demand for such solutions is changing so fast that the code is constantly being rewritten, if the code is required More replacements than persistence, then no-code tools are very suitable.
Avoid repeating the same mistakes
我认为“无代码”是一种误解。它让我们认为无代码软件是一种趋势的开始，一般软件将减少编码，软件工程也将变得更容易。但事实并非如此。软件工程与构建解决方案无关，只与开发有关。但是，随着时间的推移，改变弹性不再是无代码工具的重点，我认为这没关系。
我认为无代码工具反而是另一种趋势的延伸：重新定义工作流。过去，业务流和工作流都是以 Word 文档形式记录的，分散在各个办公室或者共享文件夹里，甚至只是通过口头在公司内部流传下来的内容。如今，我们已经有了工具，可以构建这些工作流，讨论它们，编辑它们，并更具体地分享它们。对于更多可重复的业务流程和快速完成任务来说，这是一个巨大的福音！我认为这才是真正的胜利。我认为这才是无代码工具的真正成功之处：将工作流具体化。
如果无代码想成为“传统”软件的有力竞争者（虽然我认为它不应该尝试），就需要从早期软件的错误中汲取教训。无代码工具需要理解，产品和软件系统需要几十年来不停地面对不断变化的团队和需求，面对淘汰和替换的产品、公司和标准。这需要进行文化上的转变、工具上的转变，以及作为无代码工程师在工具箱中使用的新一类抽象。每当我们尝试为无代码引入更多的工具和抽象时，我认为无代码只是得到了更多的“代码”。也许这会让我们回到我们开始的地方，并发现有代码是件好事。
毕竟，世界是复杂的。当我们针对世界的复杂性构建软件时，这种复杂性需要解决。软件是复杂的，但它所试图理解的世界也是同样的复杂。
这感觉就像我们走出了无代码的发现阶段，进入了一个我们开始理解无代码能解决哪些问题的时代。我认为重要的是，无代码工具构建者应该专注于这些优势，否则就有陷入重蹈软件行业覆辙的风险。