youri babakhanians - Fotolia

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.

This was last published in January 2018

Dig Deeper on DevOps and software development

Join the conversation

4 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

-ADS BY GOOGLE

SearchSoftwareQuality

SearchITOperations

SearchMicroservices

TheServerSide.com

SearchDataCenter

Close