If you believe what you read, low-code/no-code solutions are sent from above to solve virtually every software development problem around.
My response? Give me a break.
This is nothing new. Companies have been trying to achieve the concept of low-code software since the first punch cards containing COBOL code ran through an IBM S/360. In fact, being able to type code directly into a binary file instead of a set of punch cards was an early attempt at increasing developer productivity. Loading data from disk into memory to run code is way faster than having to run punch cards through a feeder.
Fourth-generation languages (4GL) were the first big attempt to eliminate code from coding. Instead of typing out characters in a text file, all a developer had to do was move pictures around a layout palette, and then hand code some behavior to respond to human interaction with the graphic -- a button click, for example. All the graphical layout work was done visually.
4GL languages flooded the industry, with Visual Basic and PowerBuilder being the most popular for general enterprise use.
At one time, there were tens of thousands of VB programmers making good money moving visual controls onto a form palette. I know, I was one of them. I even wrote a book about it.
Visual Basic was one of the first programming environments to support drag-and-drop programming.
Today, those products are but a faint memory in the annals of computer programming, despite the fact that some of these new low-code software products look surprisingly similar to the prior 4GL solutions.
So, why are we back here again?
The answer is that companies do not see the real problem. Yes, it is a good thing to improve tools. But, as long as the mindset in play is to just get the code out, we will remain in the Dark Ages of software development. Not much is going to change, no matter how cool the current low-code software fad is.
What do I mean by this?
From where I sit, most companies do not want to accept a few basic truths about making software. First, making software is expensive. Second, when it comes to creating code, even the easy stuff is hard. Third, no matter the amount of visualization or automation that a tool provides, anybody coding really needs to understand what's going on behind it all.
Allow me to elaborate.
Making software is expensive
It costs a lot of money to make good software. Yes, you can keep costs down by using inexperienced developers working in low-cost locales. However, without the proper understanding of large-scale enterprise development processes or the advanced knowledge required to make advanced code, you end up throwing good money after bad. Fixing bad code is more expensive than making good code.
Fixing bad code is more expensive than making good code.
The way to avoid this problem is to spend the money required to build a well-equipped technical infrastructure in which experienced project managers and business analysts can guide equally experienced developers who have a history of doing complex work. Low-code, no-code or any code software is not going work when you don't have qualified developers, business analysts and project management staff in place working in a well-provisioned technical infrastructure.
Software is expensive. It always has been and it always will be. Don't kid yourself otherwise -- even the easy stuff is hard
Anyone can't code
Years back, I was working on a project that was behind schedule and over budget. Nothing new there. The VP that was accountable for the project called the entire team into the room and told us that the project would be finished by the end of the week or, if need be, she would learn how to code to finish it off herself. She was dead serious.
At that point, I knew the project would never see the light of day. The incident would have been funny were it not so sad. Unless you have spent hours trying to get your idea to work, to absorb the seemingly infinite details required to make modern software that works, you don't really get a sense of how hard all this stuff is.
Are you hiring the right software developers
In the old days, it was enough to know a developer had the programming chops and acumen for tools to send an offer letter their way. But, these days, it's not just coding. Communications skills and business experience matter, too. And low-code/no-code platforms have made the entry point for software gigs wider than ever.
Yes, once a process is understood, it can be automated. If it can't be automated, some of the higher order production work can be made easier with a tool -- think IntelliSense code completion or something as simple as automatically displaying of line numbers in a text editor. But to expect a tool to take the place of the essential thinking that goes into software is folly.
Yet, those who are not in the know work under the assumption that if the right tool can be found, anybody can code. Well, the fact is, anybody cannot code any more than anybody can be a pastry chef or manage a construction site. What looks easy now masks the years of toil it took to achieve mastery. Ask anybody who does complex work for a living. Those in the know understand that even the easy stuff is hard.
Why the code basics matter
One of the key selling points of the low-code software movement is that it enables you to quickly create applications for common, redundant business processes without a whole lot of knowledge of the underlying languages in play. This is a great proposition. Believe me, the world does not need another human spending time writing the HTML or iOS code that has been written a hundred times before.
Composing a graphical user interface using drag and drop is a definite timesaver provided you know what's going on under the hood. When something goes wrong -- and believe me, something will go wrong -- the developer needs to have an understanding of the basic concepts that are being abstracted away by the visual tool.
For example, imagine using a low-code visual composer to bind data from a poorly written SQL query to a UI. All should work fine, right? That's the promise. Everything should be peachy keen, except that the app is slow as molasses in February. Why is it so slow? DB? UI code? The network?
Most likely, the low-code software developer won't know. He was not hired to know. He was hired to drag and drop components to create business forms, not to do data performance debugging.
Eventually, that application will end up in the work queue of someone who does know what's going on underneath the hood. What could have been done right the first time was thrashed about for days in the throes of low-code software development. So much for saving time and money.
The reality is that, at some point, you really do need to know what is going on in order to get things to work properly. Again, tools help a competent person move faster. They will not help those lacking mastery move better.
How to really address the problem
The quest for the magic tool to make it all better in the world of software development has been going on for years. Every decade, a new set of tools and methodologies appear to solve the problem the old tools couldn't. And still the problems remain for most companies, but not all.
Organizations such as Apple, Amazon, Google, Microsoft and NASA have had varying degrees of success solving the big problems that go along with making software that counts, problems that no amount of low-code software will solve.
What do they know that the others don't? These companies know that there is no substitute for excellence. They understand that it takes a lot of money, smarts and experience to make software. They know that process counts. They know that infrastructure counts. They know that you can't cut corners or expect tools to remedy flaws that are inherently due to incompetence and mismanagement.
So, then, how does a company really address the problem? Here's how:
Hire people with the attitude, history and desire required to do excellent work.
Make sure that the enterprise is adequately capitalized.
If you have to cut corners, never, ever touch project management or engineering. Postpone the executive retreat.
Do not expect tools to make it all alright. Expect tools to increase the efficiency of the teams that are presently high-performing.
Will following the items listed above guarantee success? Dunno. But, I wager you'll get far better results than the latest fad of low-code software platforms will yield.
