Will low and no code tools ever truly disrupt tech development?
Nearly everyone working in tech has an opinion about low and no code tools—believe me, I asked. Whether they code or not, low/no code incites some kind of reaction. For something designed to be so simple, its existence is surprisingly complex. Over the last several months, I spoke with developers, engineers, data analysts, CEOs, designers, and marketers about the topic. I’ll share some insights from those conversations with you here.
First, maybe a little bit about me. I’ve worked in tech for over a decade, always in marketing and communications and almost always alongside security engineers and developers. I consider myself moderately technical, but I don’t code (much). I reported a vulnerability, but I couldn’t patch it. I built a website, but I never pushed it live. I learned early in my career that research is the key to everything. So the more I heard rumblings about the rise of low code/no code, the more I researched.
Admittedly, low code and no code both seemed like ridiculous concepts at first. Low and no code couldn’t possibly mean little to no code. It means little to no visible code. I’m a moderately technical communications person in tech, so I’ve used tools like Zapier and content management tools to build things that work and aren’t the worst. The broader question remains – how will low and no code tools shake up tech development? After countless conversations, I concluded that…drumroll…it won’t.
Accessibility for building requires accessibility for learning
Low code and no code tools are designed for people like me or the couple running a pottery shop down the street. We need something easy, maintainable, and we’re not reinventing the wheel. We’re just trying to get something up and running. That means more people will be interacting with code, but not necessarily coding from the bottom up.
“The first and most tangible impact of low code comes down to accessibility,” says Matt Kiernander, Developer Advocate at Stack Overflow. “Empowering your non-software engineering folks to change website copy, build their own automations or applications all help to increase exposure and familiarity with the technology that powers your business. This exposure by extension gives citizen developers a sense of empowerment, autonomy, and ownership that was otherwise unattainable.”
This, of course, has pros and cons. The sheer number of people touching code or building what they need will grow significantly. That can be empowering, like Matt said, and chaotic. Someone building a simple automation or a quick personal website can take something and push it live quickly. When that’s not enough, things get dicier.
“One of the seemingly inevitable side effects of making software easier to build is that you tend to sacrifice customizability and a much deeper understanding of how the software works,” Jon Chan points out, Stack Overflow’s Director of Engineering for Community Products. “Low-code/no-code tools tend to look for a general use case and that can restrict how flexible that software can be: there seems to be a tradeoff between ease-of-use and control in all of these tools that I haven’t seen anyone tackle really well (yet).”
With tools available now, people will mash what they can together to create what they need, learning in real-time to get enough context to understand how to get something to work.
“Early developers blindly using low code or no code tools without learning the fundamental principles of writing code will inevitably hit a ceiling,” Stack Overflow CEO Prashanth Chandrasekar noted in his recent quarterly update. “Particularly when they have to unpack what they created.”
No and low code users will still need developers and engineers to help build their dreams. That brings me to the second big concern from developers: do low and no code tools lower overall dependency on developers? What does that mean for their jobs?
Jon reassured, “As it stands now, there seems to be a tradeoff between ease-of-use and control, and until someone figures out how to remove that tradeoff, there will always be a need for engineers who can fully manipulate software to meet the full range of use cases businesses (and individuals) need.”
Ultimately, this means that developers will be focused on more complex, hopefully interesting, work. At least in theory.
Primary concerns: work and also work
Anyone marketing a low or no code tool to developers is targeting the wrong audience. But like we’ve seen with so many tools over the years, tools used for hobbies will eventually enter the workplace. Will we start seeing low and no code tools disrupt developer workflows?
“I would be very concerned trying to use low/no code tools for software projects where performance, scale, security etc. are involved,” said Ellora Praharaj, Director of Reliability Engineering at Stack Overflow. “These tools are not designed for dealing with large amounts of data or lots of dynamic updates or for scenarios where speed matters. The low level implementation details are abstracted away from the user which makes it easy to use, but not suitable for agile development.”
With more people cobbling together what they need and learning as they go, there runs a risk of compromising security or something simply breaking without a ton of visibility into why.
“While I see low code tools being able to help data scientists and analysts iterate or experiment quickly, I do not feel comfortable using a no-code tool,” says David Gibson, a Senior Data Scientist at Stack Overflow. “Dealing with any analysis or machine learning model requires complete visibility into code and the data sources used to generate the output. Code creates a roadmap for how a number was generated. If I’m looking at a query, I can easily double-check the logic. Double checking a series of mouse clicks becomes substantially harder to check.”
TL;DR
Developers will never be out of work. Low and no code tools are making building tech more accessible, but it isn’t agile or flexible enough to replace developers.
“I’ve been hearing about low-code solutions for 30 years, only they had different names back then,” Stack Overflow CTO Jody Bailey shared with me. “I do believe low/no code is useful and it will continue to get better. Is it going to replace developers? Not in the near future, but I do believe over time it will change the skill sets required to deliver innovative tech solutions. But just like we still have developers writing assembly and C code today it is hard to imagine a time when we don’t have people writing “real” code themselves.”
The rise of low and no code tools with non-engineers will prompt more people to learn coding languages as they are building, but there is plenty of work to go around.
“There are lots of benefits to low-code platforms,” Prashanth Chandrasekar noted. “More specifically, it makes building technology more accessible to so many people. As we look towards the future, we’ll see more people developing technology than ever before, but the need for context will undoubtedly remain consistent.”
In the last 30 years some of the world’s oldest companies transformed into technology companies. General Motors, Goldman Sachs, Liberty Mutual, for example, were all non-traditional tech companies that are now leading their respective industries in tech-led innovation.
“As more people learn coding languages, perhaps prompted by low code tools, the more innovation we’ll see across industries,” Prashanth said. “Learning is the key. Developers that make the choice to learn will rise to the top.”
Tags: low code, no code
34 Comments
Of course they will impact normal development.. we are going to perpetually be called in to ‘fix’ the code someone’s teenage cousin barfed out with the latest “magic coder” tool.
This is more or less what I was thinking too. Of course it’s not going to reduce the need for developers. It will only increase it! Developers will be needed to rearchitecture when things blow up.
My consulting fees will be increasing if the majority of my load is fixing poorly designed things from people who don’t have traditional foundations in designing/implementing these systems
uh GM over TESLA? .. ok.
No code tools already exists, it’s call Excel and it’s used to run the business of million of company everywhere in the world.
The term low code has been so diluted at this point it can be used for anything. There are Low Code Application Platforms out there that can be used by developers to create complex, robust applications. It’s not the same as the bolt on tools in applications that are now claiming to be low code.
If you’d like to talk about the things you can build with low code platforms I’m happy to discuss it. I come from 13+ years in traditional development and I’ll never be going back from low code.
Completely agree with the point that it’ll never completely replace developers though. That messaging has been about forever and is as ridiculous now as it was then. It’s just another coding language the way C evolved into C++ and became C#.
I’m very interested in hearing more about those platforms you’re talking about, could you please elaborate some more, share more on how or what tools/frameworks you use to achieve this?
Are you open to discussion? adam
The perfect example of the exception that proves the rule. As the company grows, it almost always hires software developers to write programs to replace the Excel spreadsheets, as those spreadsheets become impossible to scale up.
Except that Excel is not a “no-code” tool: it’s a programming tool. For some reason a lot of people think that if your variables and expressions are mapped to names such as “A13” that are displayed in a grid rather than as lines in a text file, you’re no longer “coding.” But “non-coders” regularly build some quite sophisticated applications in Excel, especially in finance.
In the functional programming world we often call Excel a “zeroth-order functional programming language.” It uses a very functional approach, using “map”-like techniques instead of iteration with for and while loops for example.
A lot of the alleged “no-code” stuff is like this: it’s simply creating higher-level languages, often no longer written as straight text, and using higher-level and functional programming techniques. But developers have been doing this for many decades; consider the whole “4GL” (Fourth-generation Langauge) movement that started in the 1970s, or even the introduction and expansion of LISP and languages embedded in LISP in the 1960s.
Tools like Salesforce already have disrupted development. Sometimes the Low code tools are just a much quicker option out of the box for businesses with less technical skillset. But, there will always be a need for custom development which the low code platforms just aren’t designed to be able to do.
Ah, yes; the SalesForce model. Write a massive monolith that no mere mortal can understand, and then charge three figures an hour for consulting work to bend it to your company’s will.
Hey I though that was the SAP model. Or the PeopleSoft model. Or the….. well, you get the idea.
While the general theme that low/no code tools will not impact development significantly is correct, the idea that real developers will not use them is wrong, and seems to be based on your sampling of experts all coming from the same organization, which apparently uses none of these tools. Some of these tools used to be called CASE tools, and they are good for letting a developer focus on the business rules without having to worry about all the supporting code. To CASE tools, a developer or software engineer is still required, and they generate highly consistent applications with less effort than hand coding everything, just don’t look at the generated code. Many of your graphical ETL tools like Talend would count as low code tools as well, and though a data analyst would need to know SQL and how to use Excel style formulas, you don’t need to be a developer to use a tool like that, but there is still behind the scenes work to develop a full set of formulas for the specific application. Suddenly data analysts can do tasks that they might otherwise need a developer or software engineer to complete, freeing up those resources for more challenging work. One person once told me that CASE tools would make developers obsolete. That was a naïve assessment. CASE tools low/no code tools don’t make developers obsolete, they make them and others more productive so that they have more time to focus on more challenging problems that those tools can’t solve.
NoCode continues to fill the gap between
“Find an app that already does that”
And
“spend XXX time building an app to do that.”
Where nocode is a higher conglomerate of building blocks to build that app more quickly.
Developers will be needed along the whole path but more building block reuse reduces the need for the layers of lower level development.
This is a good assessment generally.
What I find happening in practice (in the business domain where I currently work – a large multinational bank), end users tend to cobble a kind of “I want to do this” via low code tools then ask development how to make this work at scale or within corporate security boundaries.
As I currently work for a large bank, we have all sorts of unspoken security checks and balances that low code tools can’t really be aware of, and low code solutions tend to go around those security checks, causing problems and headaches.
In large corporations, there tends to be intersecting problems that make a simple concept (“show me the cash flow from this bond”) into something more complex than the simple concept itself. The real problem becomes (“show me the cashflow for this bond, if I am authorized to see this”) and the “if I am authorized to see this” varies wildly between organizations and how those organizations answer that specific question.
My biggest concern with low code tools is how they meet business security and scalability needs, and given that, in my experience, every single business does those two things in relatively unique ways (at the present time), I’m not sure how valuable low code tools can be to large corporations right now. Small companies? Sure, things are simpler there.
Finally, one other observation – large scale OO frameworks became available via languages like Java 2+ decades ago. It’s within the last decade that I’ve seen large corporations creating various frameworks internally for Java, C#, Javascript, etc., and this is now leading developers to utilize these internally developed common frameworks across most or all projects within the company. Examples of these include standardized jars to provide specific functionality in Java or standardized DLLs to do the same thing in C#, or reusable Javascript components, such as React based components for inclusion in everyone’s UI’s.
Perhaps low code tools will show a similar phase-in path – when each corporation can create their own “components” used by low code tools, perhaps those tools will begin to see more widespread adoption within larger corporations.
Nice analysis. Thankyou. I’m a developer. I think I agree with your conclusions. I recently did some research into a category of development tool called source code generators. That research spun my previous slightly negative opinion around 180 degrees.
To be clear, there is a spectrum, with one-click website builders at one end and developer efficiency tools at the other. Can we class them all as low code? If so, we’re all at it already. The web development frameworks and IDE’s that we use are already making us more efficient by offering us pre-built skeletons of our code. No need to create the predictable structure of an html page every time. Who can say they never use code completion?
I now believe that there’s an audience for every level of ‘helper tool’. I myself wrote a basic tool to help people who aren’t deep into security tools to generate gpg commands to encrypt their messages using encryption keys that they control. A small step in a space where most are too intimidated to even tread.
Accessibility, yes. If we believe, as I do, that software is now ‘upgrading’ our whole human environment, then obviously non-computer scientists have just as much need to ‘interface’ with that environment. Interesting times.
Understand the skepticism that developers have about lowcode tools. But the reality is there’re a lot of tedious, time-consuming and inefficient aspects to coding, especially on the front end. As developers, we did not want to go through the same painful flow for building pixel-perfect experiences.
That’s why we built https://quest.ai, a lowcode tool for technical users. Generates clean, extendable React code pixel-perfect to your Figma designs. Build an add-on component to your existing app or build a whole new app with Quest.
I can’t help but feel that a sample entirely consisting of people who make money from the status quo of programming are going to be a bit biased on the issue.
I happen to agree with your conclusion, but I’m also the type of person to hang around on Stack Overflow, so count me in on that too.
I’d love to hear the perspective of non-technical small business owners instead. Although it’s easy to write their needs off as simplistic, these tools probably save them an arm and a leg in contractors, which almost certainly puts a dent in the software engineering job market.
To start: As a software engineer at a low code vendor I might not be completely objective.
That said, I think the most potential of no/low code is not in replacing developers but in empowering them to only do ‘the fun stuff’ in development and not being bothered by yet another one of the same projects. Lets say a no/low code platform enables a sales team to build their own order management application that would save the development team a lot of time to work on other (more valuable) projects, unsuitable for such a tool. That was the basic idea, but this idea is a bit outdated.
No/low code will never replace developers since a developer is way more than a machine transforming coffee into code. Developers have know how to build applications and why they write the code they write. Therefore, a developer should always be involved in no/low code and oversee non-developers (“Citizen developers”).
Next to that, every project has its advanced features. Say your order management needs to integrate with SAP. Good luck explaining everything about those integrations to a citizen developer. Also, would you trust a non-developer in securely building that integration? I would not. In this situation, a developer would lead development but can delegate most of the development to his team of citizen developers. The developer would only have to actually build that SAP integration into the application.
So fully replacing developers? Any no/low code vendor saying that is way behind and should not be trusted. Saving developers time and making sure their expertise is properly used, that’s what no/low code should be. In my experience developers actually become even happier when properly onboarded in no/low code projects, because they can still use their skills to write good, solid code, but only for the real challenges inside of a project and citizen developers also are very excited when they have to build a no-code function to calculate the total order value.
Lastly, remember that SAP integration that a developer has built in perfect code? What if you can make that reusable? So the next time a citizen developer needs a SAP integration, he/she can reuse that piece of developer-approved code in a no-code fashion speeding up that project big time, without having to bother a developer for that same feature again. That is where we are arriving now in the no/low code world.
Based on this, I would say the capabilities and added value of no/low code platforms have all been proven. The real challenge lies implementing a good, company-wide low-code strategy and the processes around that.
“It’s difficult to get a man to understand something, when his salary depends on him not understanding it.” – Upton Sinclair
Honestly, I don’t think just providing quotes from senior managers at Stackoverflow is really providing a balanced and rational argument for this.
I’m an old man. I’ve been doing this coding thing for 27+ years. I’ve seen countless claims of “no code” editors and platforms since Macromedia Dreamweaver launched in 1997. (And, to be fair, it wasn’t bad – but handcoding could always do better.)
But some of these current new platforms are actually properly different. WeWeb and Webflow being particularly good for front-end (and middle integration with respect to WeWeb). Xano looks really interesting and shows real promise for back-end, but perhaps not quite there just yet.
(Other development areas beyond web I don’t have the experience to properly evaluate.)
Having witnessed the constant and accelerating innovation of the past couple of decades it’s evident that shortcomings will be overcome. Exactly when / how fast is the question. To be King Canute (or more specifically his sycophantic advisors, rather than him) and say it will never happen is naivety in the extreme.
That’s not to say there won’t always be a place for well-skilled developers with deep understanding and an ability to build something outside the mainstream majority requirements – there will. But, in my seasoned observations, everything becomes commoditised over time and the (overall) intrinsic value therefore diminishes. A proper craftsman, whether a coder or a metalsmith or a draughtsman, will always have a value and with increasing scarcity a singular appreciation of worth. But overall, on balance, there will be a massively negative overall value.
Consider whether you want to embrace new tools and technologies – or deeply specialise and become the coding equivalent of Yoshindo Yoshihara for sword making – and if so, whether you actually have the dedication and natural ability to do so. Most people don’t have the serious dedication required, and the vast majority of actual, real requirements is for “good enough” rather than “perfect”.
Don’t fool yourself with your, or other’s, ill-informed snobbery to real, tangible advancement. Everything is built upon what others previously strived hard for before.
(And Stackoverflow’s huge contributIon to this is more significant than most, to be sure. These maligned and self-aggrandizement quotations by the organisation’s managers say more about them, than what belies their employer’s brand’s heritage and the true value-creators that came before them.)
No devaluation, just progression.
I think it just adds a new architectural scope. Low value, repetitive and tedious tasks can be handled by LCNC tools. However, with complex business requirements, you need custom code and a human. Someone that can work with the business to get to the bottom of the problems because more times than not, people that work in the target audience of LCNC tools just don’t have the mental chops (mostly referring to NC tools’ target audience). Some argue that AI will eventually get there. I say, not until we’re talking about full star-trek level AI where it can navigate human communicative nuance and have recurring conversations with business stakeholders about requirements and develop accordingly. And even half way to that point, you’ll hit this political boundary where both engineers and non-engineers will be fighting to keep their influence/input let alone their jobs which will more than likely spawn another field of work…
Low/no code is a topic non-technical or people with a low level of coding skills are excited to talk about. No code won’t affect the tech field and programming will keep evolving no matter the level of low code we see in the future. Bugs and code breaks will keep coming and we or the next generation will have to solve those problems
The important skill of a developer isn’t writing code in the first place. No code is just another evolution along the lines of visual development environments–it makes our job easier but it doesn’t let a non-programmer make a good system.
It will not disrupt tech development, client facing applications usually have lots of requirements around usability, user experience and performance, that most low/no-code tools can’t provide.
I believe low/no-code tools have it’s place when you’re talking about internal (employee facing) applications.
For a lot of use cases it’s a lot faster and cheaper to put something up with a tool like this instead custom developing a backend, APIs and a frontend.
Thank you. I see things are being mixed up a bit, or the borders get blur..
There‘s stuff usually called a „framework“, I.e. some ready to start codebase to build your software on.
Then there are some“higher level“ programming languages which put the hurdle to write code more towards „entry level“, JavaScript, Python, R, etc.
And then there some no/low code platforms. My experience here is that they require, not less but another set of learning path. Not learning to write code, but using those platforms efficiently. Are you a developer than because you know how to use those tools then? I would say „yes“. You produce software, and if you use a platform or a framework or a fancy IDE, these are all helpers to make it easier and support „quality“.
What I have seen and which worries me: those platforms, I must admit my experience is limited here and the biggest influencing factor is Microsoft Flow, miss out certain „best practices“ in software development. Stuff like source code management, deployment paths, automated testing I saw none to weakly supported. And then they miss out one, if not the most important stuff: maintainability. Not having the full flexibility of a native language for some requirements some „hacks“ are required to accomplish the desired. Every box has its corners. And maintaining those „hacks“ over time, by multiple „developers“, or better „software maintainers“ is challenging though.. certainly since those people, caused by the easier start into the topic, might have not the same education on architecture and design principles as a „classical developer“..
get back to me when you’re using low/no code systems to build low/no code systems
perhaps A.I. will take over where mortals fear to tread
Very good point you got there, its awesome to always hear two different point of views of the same topic.
Katrina – thanks for your piece. Let me start by saying that I’m a developer with 15+ years of experience. I now work at Unqork – a no-code platform designed for developers to build enterprise-grade applications. Your piece hit on a number of questions that we’re basically faced with every single day. Here are some thoughts:
1. The assumption that low-code/no-code (LCNC) platforms were created to make tech more accessible to citizen developers is a common one, but it really doesn’t apply to every company in the space. We market to developers because they are our core users. Our entire approach is based on the idea that developers are wasting their time on monotonous, mundane tasks that can be easily automated with no-code, thus freeing them up to do more complex work.
2. There’s no question that having citizen developers building software introduces risk – you mentioned security issues and things breaking without visibility into why. However, when enterprise-grade no-code is used by devs it actually tends to have the opposite effect. It enhances security and performance because it eliminates human error – which is the cause of the majority of security incidents.
3. There are LCNC platforms out there that are truly enterprise-grade. Unqork is one of them and we also have some competitors 🙂 We’re trusted by some of the largest enterprises in the world – and that’s because they’ve done extensive testing on our platform before using it. You mentioned that Goldman Sachs and Liberty Mutual are leading innovation…those are actually two of our customers.
4. A consideration that’s missing here is the massive time and cost savings associated with no-code – the best data I can point to is what our customers report, which is 3x faster time to market at ⅓ of the cost of custom code.
All of this said, I still agree with your conclusion that developers won’t be out of work anytime soon. But not because they won’t be using low-code and no-code – instead because they will and it will make them 10x more effective.
I run a weekly Twitch show. I’d love to have you join as a guest and I can give you a tour of the platform.
If it’s a suitable use case for low-code, use Excel/Google Sheets and forms. Anything more than that you are better off custom software development. There will always be suitable use cases, but what’s scary are decisions not made on sound trade-offs but fear. Especially if its driven by the fear of maintaining code and evolving systems because executives don’t know how to do them effectively. It’s the want to “reduce cost” because developers are expensive but development is made even more expensive by incompetent leadership and organisation dysfunction. You end up back at square one – you got your features “fast” but there’s no way to do regression testing quickly, can’t do continuous integration, no sane way to version control, no way to do decoupling where you want, constrained by inflexible UI design systems. Suddenly the euphoria stops, developers are not happy. And then your smart developers leave because you keep wanting to squeeze in more.
Test Driven Development, Test Boundaries, Abstraction, Encapsulation, Decoupling, Domain Driven Design, Event-driven architecture, Database Refactoring, Data Mesh, Parellism and concurrency, Security, CI/CD, etc… there are so many skills and concepts developed to build complex systems, there’s a reason for it. If you are going to evolve a product, stop kidding yourself. Low code already exists – tools, libraries, frameworks, cloud computing that abstracts the non-differentiated capabilities of development and operations. You can’t have both – low code and high fidelity, scalable, evolvable and mainteanable systems.
Stories like this are going to be more common https://medium.com/@michaelhenderson/why-outsystems-ruined-my-dev-job-3119828fd051
Developers will never go out of the market. However, we must understand that some developers also develop no code or low. It is simple as that canva is there in the market; still, people need a graphic designer to specifically design and customize.
Read through this article a few times and given it some thought. And I’m afraid I have to disagree with the statements in it.
This article asks the big question if Low code/no code(LCNC) will ever disrupt tech development, and the conclusion is a NO. However, it only covers what low code/no code is today.
One of my favourite quotes from the article is
“I would be very concerned trying to use low code/no code tools for software projects where performance, scale, security etc., are involved”, and another one says that low code/no code is not suitable for agile development.
These quotes give me the same feeling as Bill gates famous, “640K of memory is all that anybody with a computer would ever need.”
Being a developer and forward, looking I am very sure that in the coming years, scalable and secure web and mobile apps will be possible to create with LCNC tools and require significantly less technical knowledge.
LCNC will never replace developers. But it will remove 90% of our mundane, repetitive work and do it better than most developers.
I think this is a healthy evolution. LCNC will contribute to addressing the developer shortage and let developers focus their skills on more innovation and less repetition.
@Katarina Dene. A delightful read, and thanks for sharing your and your team’s thoughts on this topic
I took some time to add more detail to my thoughts in this blog post.
https://nebulr.group/empowering-non-developers-to-fix-tomorrows-developer-demand/
There are many skills and theories needed to be an effective developer. Among these are object theories, data normalization, etc. To the extent that low code develops software without designing data, perhaps it will work. I don’t believe there are such low code environments,
Yet there are computer languages that can improve efficiency. For decades many organizations have used PL/SQL to manage their processes and data. It is a simple language and if you know SQL you can learn in about a week. Similarly, DMN /FEEL is extremely powerful and easy to learn.
I’ve testes a few lowcode/nocode tools, the main takeout for me was that it was considerably slower to develop what is basically solved by most frameworks today.
Granted I don’t have much experience, but I think a code-generator / dynamic-generator with the hability to allow people with no code experience to modify application views from a visual tool would be the best case scenario