There has long been tension between traditional developers and the use of NoCode tools. Developers are often resistant to non-developers writing applications because they either fear that they are encroaching on their role or because they are concerned that it will produce solutions that are harder to scale and more difficult to maintain. While some of this concern is founded NoCode is just a natural evolution of how software gets developed and is actually a good thing for software engineers.
Every software engineer uses libraries of code to help them develop faster and not have to re-invent the wheel. Typically most code in an application is actually comprised of 3rd party libraries that the developer has integrated in order to save time. When developers code they often do so in complex Integrated Development Environments (IDE) that makes them more efficient by providing code completion, inline bug checking and other things that help them. Additionally, no application developer writes code in assembly anymore, they all use a higher generation language that attempts to make writing programs more efficient. NoCode is just an extension of this that essentially makes building an application a process of configuration through a visual interface rather than writing code.
Developers often perform the same task repeatedly. The so called CRUD, an acronym for Create, Retrieve, Update and Delete, is something that every developer has likely done over and over again to the point of exhaustion. Most NoCode tools are just providing a visual interface to configure these CRUD’s.
NoCode is essentially an interface (typically a web application) that lets you build applications without having to actually write the syntax of a programming language. All NoCode tools are built using code and are created by software developers. NoCode applications themselves are quite complex and require high-end software engineers to build.
Writing a NoCode application is actually programming. It’s just using a visual interface to define how the application will work instead of writing actual words in a programming language. Programmers have always tried to create higher-level languages to make it easier and quicker to develop. There are so-called programming language generations. To start there were First Generation Languages where code was created using 1’s and 0’s. Then came second generation languages which were assembly languages where basic commands (such as “LDA A”) were represented by short commands that could be understood by a person. Then came third generational languages such as C, C++ and Java. These languages are much more programmer friendly. There are additional generations of languages and it could be argued that NoCode is a 5th generation language. Fifth generation languages attempt to make a computer solve a problem without a programmer.
NoCode lets software engineers focus on more complex problems rather than building the same CRUD type interfaces over and over again. These sorts of easy types of interfaces can be handled using these NoCode tools which frees up software engineers to focus on more complex and interesting problems to solve.
NoCode tools are some of the most complex applications to create. Enabling non-technical people to build relatively unconstrained applications is not a simple task. As nocode grows so will the need for developers to build, maintain and enhance these tools. If you look at any growing NoCode tools web site and see what sorts of positions they are hiring for, you will likely see some very technical requirements. For example, a recent job posting from Bubble suggests the following programming stack.