Will Low Code/No Code Kill Programming Jobs?

Low code and no code are ideas that are gaining traction. Low-code development platforms are used to solve all sorts of software development problems, but what is no code development, is this a new idea that will take your job, or is this another attempt at an old idea and some kind of no-code bubble. What is the effect of low code on programmers, and the organisations that employ them? What are the pitfalls to adopting low-code solutions and what should you do to avoid them?

In this episode, Dave Farley, author of “Continuous Delivery” and “Modern Software Engineering” explores the use, and problems in using, low-code for software development. Computer science and software engineering have evolved strategies to deal with the complexities at the heart of software, but can low-code really hide these complexities? Dave describes some common, maybe unavoidable problems and discusses what you need to do to avoid them.

_____________________________________________________

🔗 LINKS:

_____________________________________________________

📚 BOOKS:

In this book, Dave brings together his ideas and proven techniques to describe a durable, coherent and foundational approach to effective software development, for programmers, managers and technical leads, at all levels of experience.

📖 "Continuous Delivery Pipelines" by Dave Farley

NOTE: If you click on one of the Amazon Affiliate links and buy the book, Continuous Delivery Ltd. will get a small fee for the recommendation with NO increase in cost to you.

-------------------------------------------------------------------------------------
Also from Dave:

🎓 CD TRAINING COURSES
If you want to learn Continuous Delivery and DevOps skills, check out Dave Farley's courses

📧 JOIN CD MAIL LIST 📧

-------------------------------------------------------------------------------------

CHANNEL SPONSORS:

[joegolike]

You can replace “low code” with “AI/ML” and every point of this talk is still spot on.

[clout]

After falling for the "nocode/lowcode lie", that you can "building anything you can imagine without writing code", I abandoned programming and started to look into nocode tools, at first I was amazed and extremely happy that I'll finally be able to launch products without having to spend months bashing my head against the keyboard, trying to find why it doesn't work the way it should. Fast forward 3 months I'm back to coding, I have a slight disgust every time I hear about nocode/lowcode, and it's going to take A LOT for a nocode/lowcode platform to convince me to give it a try in the future. Long story short, of course it was all a lie, I couldn't "build anything you can imagine", I could barely build anything in fact. I built on 6 nocode platforms (glide, bubble, adalo, appgyver, flutterflow, backendless), and looked into many more, none of them were able to build a serious high quality, complex software product. Some of them came with a predefined user interface and didn't allow you to edit it (wtf?!), some of them straight up lacked basic functionality (seriously how tf am I supposed to "build the next airbnb" if can't even make an element invisible...), some of them were so complicated and hard to use that it would've been easier just to write code (oh, the irony) and some of them straight up didn't even work ("where was an error processing your request please try again later" yeah thanks bro) . So in conclusion, don't do the same mistakes I did, lowcode/nocode is okay if you want a small little app for an MVP or to impress your mom and you have no intention of learning to code. But if you already know how to code and/or want to build a serious software project, stay as far away from nocode as possible.

[aytviewer]

I've been working in the IT Industry for 30+ years now (started when I was 18!). About every 4-5 years a wave of low-code/no-code solutions appears and each time they claim that programmers will be made obsolete and companies will no longer need to hire coders. There are very slick demos that seem to magically enable average business users to create data entry screens and generate reports without writing nary a line of code. This tools are scripted demos with limited application to providing solutions for the real world. As soon as the user tries to do anything off script, it is either not possible, or needs a developer who understands the underlying data (and SQL) to get the data that the user desires. The data entry screens are usually very generic and apply little validation on field input except for perhaps a static mask. The tools are very limited. After being through many cycles of these types of claims over the years, I now ignore the hype and give it little notice.

[edwardcullen]

I have some experience with low code development with one of the large (largest?) low code platforms, in a legal context.

The best summary I have, I credit to a colleague: "It's great for rapid prototyping."

From my perspective, it was just like any other tool in engineering: you end up replacing one problem with another; you're shifting the complexity around, rather than fundamentally reducing it.

Biggest problems we had was around architecture and lifecycle management.

Unlike (usually) .NET or Java (or dynamically linked C/C++), when the platform needed updating, the application needed to be rebuilt - and therefore retested.

There were also architecture problems - because the app had been developed by non-programmers, they didn't have the of how *GOD AWFUL* ORMs can be and the dangers of accidentally slurping vast quantities of data over the network.

There were also other issues - bugs that couldn't be diagnosed and corrected by someone who understood lower-level HTTP/HTML and Java (yes, me... And I *loathe* Java 😂)

Another MAJOR downside was the cost - the infrastructure was EXPENSIVE, *plus* we had lawyers writing software... Essentially, we ended up with untestable, poorly functioning software, written by amateurs that was extremely expensive to develop and run... And a bloody *nightmare* to maintain!

It was great for the lawyers, because they had the sense of involvement, control and progress (all the things lawyers are predisposed to), but the cost of delivery was insane - it would have been FAR cheaper to employ a couple of good/experienced devs full-time and use cheaper infrastructure (even public cloud...)

Like I said, it would be good for prototyping: let the lawyers sketch-out something that kinda does what they want, but then had it over to experienced devs to "build properly".

[Caldera]

I've met plenty of academics who could code just fine, but weren't great developers. I've known business analysts who could do things with SQL just fine, but they struggled with engineering the flow of communication between critical parts of the system. Even if my IDE could write my code for me on my current project, there's more going on in the aircraft than the code inside one part of the system. There are so many different sensors, comms systems, and other things that make it difficult for me to imagine no-code or copilot style software is capable of envisioning a solution that the customer actually wants for complicated systems like aircraft, large games, exchange systems, etc.

At my last job, I ran into a wall of project managers and C level execs who were trying to push Microsoft PowerApps for more and more client facing solutions. I didn't stick around for the result, but last I heard, the client wasn't happy with the end product.

There will always be a need for software engineers for as long as computers exist in their current form.

[AdamJorgensen]

I've been experimenting with Github Co-Pilot lately and I think it has far more potential than any of the Low-Code platforms to be useful. I don't think it's going to replace developers, but I think it will definitely help us deal with certain tedious tasks much more easily (I've found it's particularly good at helping with boilerplate, filling in unit tests and helping write documentation)

[sirtobi]

I am currently working on a project where we had a low code/'no code' environment. Now I have to port everything into a mixture of C++ and Python because the 'no code' version was way too slow, resource-heavy and some features would spontaneously stop working. I don't think that programming jobs will be affected that badly. Because libraries literally do the same thing as 'low code' environments. You do not have to code them yourself and we all still have our jobs.

[mattdizak]

COBOL was developed to be the language that would cut software developers out of the loop and allow businessmen to write their own software. I would imagine the same will happen with this no code / low code fad, same as in the early 2000s when WYSIWYG editors were this huge fad and look how well that turned out.

[ronaldomorillo]

Excellent content as always, Dave!
I used to work for a company that drank the low-code kool-aid and ended up migrating to custom code (due to extremely slow turn-around time to crank out new features, poor debugging/testing support, and unexplained performance issues) and never looked back. As for the job security threat non-sense, programmers are still needed to pick up the pieces whenever low-code systems blow up, so don't panic.

[ruibarbosa]

Hi Dave, I'm a developer advocate for a low code development language and your videos have served me well in demonstrating to developers that they are not going to burst into flames and low code development is the same as traditional development from a problem solving perspective.

The advantage of the low code development tool I use is just an abstraction layer, NOT for problem solving that stays the same, but for the repetitive, dull, tasks of writing the code in a specific language itself.

For example, I develop using the same tool independently of where this code will end up, i.e. JavaScript for the client side and C# for the server side, of course I'm very ware which is which but I code the same way.
Every single method I create, their calls will be automatically logged and timed for performance.
Calling a server side method from the client side is just a simple "low code" call that gets implemented as a secured REST call to a server method with all parameter parsing so the client side can send and receive the result.
This is the power of low code.

The use case this tool covers is web development. Sufficiently broad to support the development of a banking b2c app, REST API’s or Wordle, making the problem domain far from well known.
It does support version control, debugging, logging, testing, modularity, cohesion, abstraction and information hiding, also CI/CD but only very short lived branching.

From my perspective it checks all your boxes from this episode and most from your previous videos.

So here is my hypothesis, I believe you haven't been exposed to low code generic development tools that can create applications for generic use and those applications can technically live outside of the platforms that created them.

Would you like to do this experiment privately?

[tylerlwsmith]

No-code solutions scared me when I was earlier in my career because I thought that they would make me replaceable. I now understand that software engineering is about managing complexity and enabling change over time. Low code tools don't really introduce any new or compelling solutions to either of those problems.

All of that said: writing code isn't intrinsically valuable, it's just one approach to solving problems. If you can solve problems with less code then that's probably a win.

[YeOldeTraveller]

When I was in school in the 80s, one things was said about software development was that coding itself only accounted for about 5% of the development effort. I expect that number is even smaller today. As you point out, the actual task to solving a problem. That task is not addressed by any of the low code solutions I have seen when they arrive every few years or so.

I remember the first one was a tool where you didn't write code, you connected functional blocks together. Many were worried about that. i figured that was great, but that someone was going be needed to write the new blocks as new capabilities were required. Most low code fits this model. At this point, I see no chance that my job will be eliminated before I am ready to retire.

[rtpHarry]

My problem with low code / no code is that even if it seems like it solves your problem you are then setting the client up for failure in the future. Most of these solutions are small companies that might not last long, and usually they want to host the solution in someway. Plus by the time you bump into the edges of the system the client is already deeply invested in it. So it would have to provide such great value in the short term that it wouldn't be all cancelled out with the costs of migrating away from it after a certain point.

[anb]

Wordpress, wix, squarespace etc didn't replaced web developer jobs, instead tools like wordpress by allowing everyone to have a website, indirectly promoted new markets for developers to develop custom themes, plugins etc.

[Rand]

Great talk and communication too. And an open-mindedness I would never have.

You are pointing the real great problem of no-code: no-code means no code lifecycle management. And that's a source of disaster. I always find my team importing stuff from Production to realign things in Development, or redeveloping things after being released to adjust small bits here and there.

Also, the no mistakes allowed philosophy really bugges me. If I develop an unnecessary component and release it by mistake, some no-code tools under certain conditions will never allow me to remove it.

During my work days I find myself saying "Were it code, this wouldn't happen" too often.

[calkelpdiver]

I've heard this one before. Back in the early/mid 1990's we had CASE tools that were going to revolutionize software development. It was a bunch of vapor that just went "poof!"

[mattcay]

I don't think low code/no code solutions could ever truly replace programming jobs. After all, programming at its core is nothing more but a way to formally specify our requirements on behavior and a programmer's job is translating highly-abstract human-level wishes and desires into highly formal computer-level specification. Until we have human-level AI that can understand human intention and translate it into machine code, programmers will be needed to do that translation.

Higher-level languages can certainly be useful since they allow us to combine "pre-packaged" formalizations and not do all the nitty-gritty details each time, but at the end of the day, the rubber has to meet the road somewhere. It seems to me that low code/no code might certainly be useful if our use case is so common that those "pre-packged" formalizations are feasible to define on a very high abstraction level, but I think that ultimatetly they'll likely end up as just another tool that can make programmer's life easier. There are simply too many problems to be solved for the super-high-level abstractions to be flexible enough--as evidenced by what you've mentioned in your video about the trade-off between the system's flexibility and the solution looking more and more like code.

[karlwaugh]

Excellent talk. I really enjoyed a) the fact that the mid roll advert was for a "no code solution" b) the use of examples from your own experience (sometimes you can be very theoretical and I find it helps to illuminate the subject you're talking about) and c) this being a dive into a bit of a side subject, something we come across but don't necessarily have the time to dig into personally.

Good work

[FreedomMoped]

The levels of complexity required come from the business problems not the coding tool.

So difficult to get this through to those in leadership.

[SmashTheCache]

I'm in charge if product management for a data driven business application used nationwide with complex role based functionality. I couldn't be where I am without low code. I also couldn't be here without complementary custom development.

These two things are not mutually exclusive. They are AND, not OR.