We have such a fixed idea of what programming is, it almost impossible to imagine anything different.
In 1984 I used a computer for the first time. I tried a Macintosh, but it seemed to too simple. I intuitively felt that I wouldn’t be able to do anything interesting or complex with it. So I got an IBM PC and a copy of Lotus 1-2-3, and I was satisfied with the ridiculous complexity of figuring out interrupts, navigating the world’s most broken operating system (DOS), and coping with memory so small that it could only hold about 5 pages of text before it exploded. Now that was s serious computer!
I gave up on it and didn’t touch a computer again for a year or so, at which point computerizing my production office seemed inevitable. I researched computers, and this time bought a Macintosh Plus because it could be configured with six times more memory than a PC, and that seemed important to me. The salesman also sold me a programming language called Omnis, and I proceeded to teach myself how to program a fairly complex system for film production.
It turned out that the Macintosh’s simplicity of use did not prevent me from accomplishing complex programming. As I dug deeper into programming, learning Pascal, C and Assembly Language I came to understand that the Macintosh’s apparent simplicity was the result of incredibly sophisticated and complex (for the time) programming.
One of the hallmarks of expertise is a real expert makes things look easy. Babe Ruth and Rory McIlroy seem to be barely breaking a sweat. How many guitar players have listened to Eric Clapton’s opening bar of Hideaway and thought to themselves “That’s easy, I could do that”?
It was a mistake for me to believe that the Mac wasn’t powerful because it was easy. The fact is: it was easy because it was powerful.
Most people have a similar mental block when it comes to visual development, also called “no-code” development. We are so used to thinking of programming in terms of typing a strange language in green letters on a black screen, that it creates an unconscious bias against anything that is simpler, easier. Once again the truth is the opposite: it takes considerable skill and sophistication to create a good no-code platform, but once it is done right, it is powerful. In some ways more powerful than traditional programming on that green screen.
I can almost hear some of my readers saying “Hold up! Slow up! That can’t be right.” But let’s think about cars.
Just about 100 years ago, cars were built the way we build software today. A car could not be built without master carriage builders and master mechanics. Each car was built from start to finish as a one-of product. Parts from one car could not be just switched to another. They would have to be machined, fitted. This system of production is not scalable. To build many more cars, one would have to find many more master craftsmen, and there is not an unlimited supply of those. Also each master works in their own fashion, slightly (or very) differently than the next. There can be no standardization, no economy of scale, no consistency.
You would not expect an application development project to be successful if all of the programmers were either inexperienced or not very good programmers, you must have one or more master programmers from the start of the project until the end, and when we take a chink of code from one program and paste it into another, we have to go through it very carefully, individually fitting it into its new home. And… there is not an unlimited supply of master programmers, each master works in their own fashion, slightly (or very) differently than the next, there is no standardization, no economy of scale, no consistency.
Today, the process of building a car is very different. Designers and engineers work very hard for a few years preparing a new car model for mass production, testing designs and building the tooling for the production line. When the car goes into production, the designers and engineers move on to other projects, and the cars are assembled by robots and semi-skilled labor, workers with no design or engineering training. And it scales. Need more cars, just add a shift to the factory. Or build a new factory and hire more workers, who with no professional training are much easier to find than engineers and designers. Quality is better too. Because of standardization, quality and the consistency of that quality is astronomically higher than it was 100 years ago.
No-code platforms follow the same philosophy. Careful design and engineering produce an inventory of interchangeable parts that can be assembled into an app by workers unskilled in programming. Because the code has been written, tested, and debugged before it is used to create an app, the apps are robust, bug-free, and production-ready as soon as they are built.