BACKGROUND IMAGE: iSTOCK/GETTY IMAGES

This content is part of the Essential Guide: Pros and cons of a low-code platform for mobile
Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

Why the promise of low-code software platforms is deceiving

Low-code/no-code platforms mean anyone can code, right? Wrong. Columnist Bob Reselman explains why this is a dangerous thought for enterprises.

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
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.

Join the conversation

10 comments

Send me notifications when other members comment.

Please create a username to comment.

How does low-code/no-code fit into the future of software development?
Cancel
We jumped on the low-code bandwagon because it meant we could ride the wave of other companies advertising. 

Like you have said it's just a new word for a thing that has been around for years.

MS Access was a great tool but didn't really make the jump to the cloud.

What bothers me about most low-code alternatives is that their offering handcuffs users to their Platform as a Service.

Cancel
+1
Cancel

Hi Bob,


My apologies for the length of the comment! Interesting read, you make some good points, but I do feel you are missing a critical element of no-/low-code development. I’m curious how you feel about this.

Let me start by saying that there is a clear separation between low-code and no-code. And for good reason. I’ll get back to this later. In my response, I’ll mainly focus on no-code. Reading your article, the title attempts to demystify a concept with another misconception:

'Low-code/no-code platforms mean anyone can code, right? Wrong.'


It’s true, you clarify that low-code/no-code platforms do not mean anyone can code, but that’s also not the full purpose of these platforms. The purpose is: Anyone can build an application and you don’t have to know complex code to do so. (Again, this only applies to no-code platforms.)


Also stated in the article, these (RAD) tools are nothing new, but anno 2018, they have evolved.

No-code is used to enable employees (citizen developers) to initiate solutions in an environment structured by IT. Once more robust infrastructure is needed, IT takes over. So no-code isn’t just about creating an entire solution where complex code is otherwise needed, it’s also intended to drive innovation by empowering non-traditional developers to build the base of solutions.


To get back to the no-/low-code discussion, low-code simply means using less code. Processes will go faster but you still have to be a developer and understand code. It will lessen the burden of repetitive tasks and the basics will be preset, so the process will be faster. Adjustments to an application are more easily made, but often it requires IT to do so.

With advanced no-code platforms (e.g. Betty Blocks), anyone can build applications, but it does require some affinity with the process. (Which is something very different than being a skilled, traditional developer). The low learning curve of such a platform enables employees from different lines of business, to make a start and enable innovation (within a IT controlled environment). When citizen developers make a start, IT will take over at some point in time, thus bridging a gap between business and IT.


A few of the benefits of no-code:

  • Anyone can be a no-code app builder (low learning curve, often 1 week of training is enough)

  • Enables company innovation

  • Very flexible in making adjustments or expansion (don’t have to depend on IT)

  • low TCO

  • You can start right away (no need to download software)


Regarding this part of your article: 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.


I very much agree, but you cannot compare technical skills with vocational skills. Like many technological concepts, a layer of abstraction enables anyone to participate.


Since traditional coding also has it downsides (hard to find skilled developers, very repetitive tasks, prone to errors, high maintenance, etc.) a combination of the best of both worlds can be very effective and efficient for any company.  


Like I said, I’m curious about your take on this!


Cancel
This is a very wise analysis. The only add I can offer is that having a well developed ability to abstract is essential for making software. Yet, I find that many of those interested in coding tend to become fascinated with the syntax of a programming language rather than the semantics. e.g., knowing how to make an anonymous function is a necessary skill. But, being able to understand the value and benefit of an anonymous function is equally important, I think.
Cancel
Definitely. the syntax is searchable the algorithmisation is esential. 
Cancel
Hello, I have an opinion about the benefits you listed, I'm not trying to be a contrarian, but with the experience I had using no code platforms I think the are certain points that can add more information about what you said:

Anyone can be a no-code app builder and you can start right away, yes to some extent, but many times the apps that our clients need require specialized knowledge (that takes a lot to time to learn, months or even years) about the platform to develop functions or pay someone knowledgeable to do it or sell you the solution, which in my experience affects TCO gravely and while at the same time it gives you company more knowledge and innovation it too limits you when you need to change from plataform to plataform, almost forcing you to only stay with one low code for the rest of your life, also some low codes (like zoho, for example) while expanding it is easy, it can start to break (in logic and performance) if you expand it too much and that ends making the program of no use and you as a developer or product owner have almost no control about it, just like Bob touched in this article.

Greetings.
Cancel
Great article! I think low-code is the future! This platform is amazing - https://www.codejig.com/en/builder/ check it out!
Cancel
I agree with this thinking. I personally use low code, but I have 20 years experience using Visual Studio. Low code produces applications built with consistency and much easier to maintain. However, I strongly reject the concept of "Citizen Developer." That only creates chaos and promotes shadow IT. Low code platforms in the right hands can indeed speed up production. But in the wrong hands can be devastating.
Cancel
Linking the calculations, data store and UI. 

I find I need code for 2 main reasons.
 1) I need code so my calculations control my UI.
 2) I need code so my calculations control my data store.

I mostly need code to link calculations, UI and datastores. These are the main reasons I need code. So I created a another way to handle the problem. I is very work in progress. I would be interested in your thoughts.     https://www.youtube.com/watch?v=R-oDB1PDWqY 

Cancel

-ADS BY GOOGLE

SearchMicroservices

TheServerSide.com

SearchCloudApplications

SearchAWS

SearchBusinessAnalytics

SearchHRSoftware

SearchHealthIT

Close