Two views of low-code development

Back in 1975, Prof. Dijkstra wrote, "In the world around us we encounter two radically different views of programming. View A: Programming in essence is very easy. View B: Programming is intrinsically very difficult." He saw view A as the common cause of many mistakes, one of which was overestimating the benefits of high-level programming languages. At the time, high-level programming languages were already by themselves a major leap in the history of computing.

Take COBOL for example. It was thought to make programming by professional programmer superfluous by allowing user to write down what he wanted in plain English that every one could read and understand. But instead of ridding organizations of all programming problems and software crisis, five years after the high-level language was invented, COBOL had a completely opposite effect. It became a major programming vehicle for ever growing numbers of professional programmers, who still produced, as willingly as before, large chunks of un-understandable code. The only difference was that "now they did it on a more grandiose scale, and that high-level bugs had replaced low-level ones". The advent of high-level programming languages, Dijkstra noted, had not reduced the essential need for accuracy, and many other qualities required in a good software.

It did not take much to find these two views again in the world of low-code development today. The difference between those who held view A and B, I would have guessed, lied in their answers to these following fundamental questions: Is code written for a machine or for a person? Are business users the only customers? I suppose those who held view A would say programmers write code for machines to read and business users, who used (and hopefully paid) the software, are the only customers they need to care about.

The advent of low-code tools in today's world to high-level programming languages is as much as they themselves were to low-level languages back then. It removed the trivia and drudgery of small details and allowed programmers to operate from a higher ground of abstractions. For decades, we haven't had to worry about writing codes so that the machine can understand. Therefore, regardless of tools or languages, programming has become more an act of communication from one individual to another , a social act. Good communication is clear, simple and free of clutter. And making "good communication" is no easy task. Try asking a professional writer about it.

But seeing the social dimension of codes is just the beginning of a mindset shift. Software is rarely developed once and done, meaning it evolves with the people who extract value from it. As the number of people who are and will be interacting with the codes over the lifetime of the software increases, it's no longer sufficient to keep in mind only the needs of business users. The software requirements, I believe, must take in the needs of those who will support and interact with codes in the future. Take readability, reusability, testability, to name a few.

Perhaps Dijkstra was right. To explain the tenacity with which so many people cling to view A, psychology needs to be brought into the picture. It was not so much the software vendors who want to sell more license, or managers who would like to view programming as simple or predictable activity. It was our human tendency which crave the comfortable illusion of a magical tool that makes hard work easy, thereby freeing us from the hard realities of creating good software.

Please! Try not to fall into that trap of thinking low-code is easy. To produce proper output, one must be in proper state of mind. Only by accepting it as a hard intellectual challenge will we be properly prepared to meet the challenges of our profession. And, amidst the exhaustion and looming deadlines, if you find your mind drifting to the easy choice of being satisfied with "working codes", permit yourself a break and come back. Because programming well, in whatever tools or languages, is simply hard.