The No/Low-Code Movement

Do programmers have a future with no/low-code systems? After noticing some trends over the past month, I wanted to share my opinion of this approach to writing, or rather not writing, code.

Even though I was extremely busy this week, I was able to find some interesting posts about no/low-code movement in our industry and decided to give my opinion on this subject.

I know last week in my newsletter (discontinued in March, 2022), I mentioned my first breadcrumb called Why Software Developers Might Be Obsolete by 2030.

Well, during this past week, there was even more content to digest.

The latest Technology Radar from ThoughtWorks was released and the second breadcrumb in the report mentioned no/low-code movement trend.

For those new to the Tech Radar, it's one of my go-to reports I read on a regular basis to keep up with technology trends. Under the Techniques section, they mention companies should Assess the technology of "Bounded low-code Platforms" (number 14). Their definition of assess means "worth exploring with the goal of understanding how it will affect your enterprise."

Even though they mention this technology with new competitors entering the market, they're still skeptical about the technology.

I feel the same way.

After reading the Tech Radar, I started seeing more posts about the No/Low-Code movement on my newsfeeds and announcements.

The next breadcrumbs that caught my eyes were the articles When is No-Code Useful? by Linus Lee and an August post titled Could the No-Code Movement Put Programmers out of a Job? on Forbes by Enrique Dans.

Both present interesting perspectives, but both share the same argument of the world being too complex for a no-code movement to gain any traction.

The final breadcrumb was a developer mentioning it to me this week. They asked, "Will developers have a future with a no/low-code movement?"

Personally, I'm not worried about it and developers shouldn't worry either.

As I sat there thinking about it, this scenario felt awfully familiar.

Maybe it's because I feel it harkens back to the days of when executives would use Visual Basic to design screens by clicking and dragging elements onto a form and then self-proclaiming themselves as a programmer.

Or lately, someone installing a CMS and clicking and dragging components onto a webpage and also claiming they're a coder. 

Yet, I'll give these no/low-code systems the benefit of the doubt and present 4 other reasons why I'm so skeptical.

1. Who builds the no-code systems?

We still need specs and have to design the modules to create the "code." It's simply a higher-level of abstraction, but we still need developers.

2. Large teams (a.k.a. too many cooks in the kitchen)

As mentioned with the posts above, there is usually a large amount of complexity in systems, but I don't care what no-code systems are out there, they will never reach enough granularity to entirely satisfy complex business requirements.

MAYBE you can achieve this with low-code systems, but in my experiences, if you introduce a hook in a low-code system allowing you to write a minimal amount of code, it will turn into a 1,500-line piece of code in a low-code system (<ahem> VBA app in Excel, anyone?) 

3. Version Control

How do you version something that has no code? What if you make a mistake? Can you revert the design back to a checkpoint?

Honestly, how would a versioning system work with a no/low-code system?

4. AI-built systems replacing programmers

We're now at the starting point where AI systems create rudimentary programs to solve small problems.

While AI may be great for building small utilities, there is something to be said for building systems with a team of real developers with experience.

AI-based software would look through pre-programmed patterns to determine the best approach, but this could be seen as a novice developer approach.

Think about the saying "If a developer has a hammer, everything is a nail."

When AI-based software is trying to solve a problem, it may solve it with the first pattern it successfully finds. However, as doctors say, the solution may fix the symptom, but won't cure the problem. There could be other design patterns matching the scenario, but meant to be better long-term situations as opposed to fixing it immediately with a quick fix.

This is where experienced developers enter the picture and provide more insight as to what's important for scalability and maintainability for future work.

Conclusion

Even if no/low-code became more of a trend in the coming years, the amount of change a company would have to make to their infrastructure would be the equivalent of the Titanic trying to turn on a dime.

I would not see this as a 5-year plan. Depending on the complexity of the company's business rules, it would be more like ten to twenty years.

After that long-winded opinion, I'm sure others have a different opinion about no-code or low-code systems.

Do you think these types of systems will replace programmers? Or do you see it helping programmers? Post your comments below and let's discuss.