The “no-code movement”: will programmers be put out of business?
In a way, no-code isn’t a new thing: ever since we’ve added GUIs (Graphical User Interfaces) to our programs, or that we’ve created WYSIWYG (“What You See Is What You Get”) editors, we’ve searched for ways of making the life of programmers easier. Pieces of software like WordPress or IFTTT are different, yet they both have one goal in common: automate some menial tasks to take away the complexity and bring more people to the party.
Note: I’m glad to say this article has recently been cited on LinkedIn and in an article on ZDNet by Joe McKendrick :)
For the past few years, the no-code movement, or “low-code”, or “visual development”, has been a growing trend. We’re now surrounded by new technology: mobile apps, websites, social networks… it’s no wonder more and more of us want to take a peek under the hood! The number of coding courses, programming Youtube video tutorials and computer science schools has been booming lately. So, with an ever increasing interest in creating online portfolios, coding up small iPhone utilities or apps, the idea of making computer science accessible to all has grown in the community.
Today, big players like Google, Amazon or Microsoft offer “no-code tools”: App Maker, Honeycode, Flow… There are plenty of platforms nowadays to create various apps or bits of code easily with just the touch of a button. They’re taking in to the next level and actually raising the question: could everyone become a developer? could programmer jobs become obsolete?
The benefits of no-code tools…
Thanks to these tools, coding could become a mainstream hobby. People could get a better understanding of how the products and software they use everyday work. Moreover, it would give plenty of enthusiasts from the broad audience a chance to build, maintain and master the programs they continuously live with.
In startups or small companies, it could also empower users (also called “citizen developers”) to be part of the implementation by helping out with tweakable and scalable contributions. It could light the creative spark in many “makers” and “pioneers” that so far were blocked by tech constraints. The challenge is to give them a true insight into the tools so that they don’t just run along blindly! I’ll admit I’m cautious of the idea proposed in this article by Kate Kendall:
All in all, users don’t need to understand code to be able to create an app and therein lies its power.
Note: it’s really interesting to see how this author — and others who also are entrepreneurs — have a very different take on the subject than developers. Overall, the later seem a lot more wary of this new trend.
I believe spreading the word about the inner workings of software is paramount because it likely won’t dim down in the years to come. Rather, I expect we will see way more of it. Thus it’s up to us to enter the realm of coding and go beyond a mere usage of the products. We already see the will to give the next generations a better understanding of software with some educational projects that start to teach coding in primary schools.
And by the way, the ability to quickly prototype something is not just a nice gift for non-developers: as a programmer, you’d often like to have some “quick sketch sandbox” to test out stuff, so this could be a sweet alternative to Github templates or tutorial bundles. As a professional, it’s also a great opportunity to automate the most boring tasks in your work pipeline: auto-machine learning solutions are sort of a case study for this because they offer to take dumb data processing, basic feature engineering and even model deploying off of your hands (e.g. Prevision.io — the startup I currently work at — or H2O).
Going one step further than prototypes, there also are some types of software a developer is not at-ease with; we all have specialties and we cannot branch out to learn about everything — computer science advances so blazingly fast it would be an inhuman task! Sometimes, it’s more about time: I myself use WordPress for my blog because it allows me to speed up lots of steps in the process. So, even though I could get a more customized, perhaps more optimized website by coding it from scratch, I have to put the required time in the balance and estimate the tradeoff. To me, this is how the no-code movement could even attract some professional coders: we regularly find ourselves in situations where the gains of a simplified easy-to-setup framework could far outweigh the loss in tech choices and visual customization!
… and the drawbacks?
On the other hand, the no-code movement faces some issues with its core principles.
Can you really learn programming that easily?
Two weeks ago, I wrote a little article on my blog about teaching and learning. In particular, I spent some time on why I think the deep understanding of a topic is crucial in the ability to “transfer your skills”. Remember that if you just learn by heart the solution to 100 questions without ever reflecting upon the possible links between each of them, then you’ll need to learn 100 solutions; if instead you discover that there is but one concept that underlies the 100 questions, then learning 1 process to solve problems with that concept allows you to instantly solve this set of questions.
With no-code tools, I don’t know how much of a “global knowledge” you acquire. Sure, you’ll get used to the tool and may grasp some of the theories behind it, but I think solely relying on no-code products as an introduction to coding is a risky way of entering the world of programming. You might miss some common concepts just because it’s not presented the same in two different tools, or you might overly emphasize a step of the process because it seemed particularly in the spotlight on this particular platform… All in all, I’m not sure how much of a bird’s-eye view these tools give you — and therefore how much of this holistic-deep understanding they give you on the matter at hand.
So perhaps the question shouldn’t be: ‘can you really learn programming that easily?’, but rather ‘what can you learn of programming with this user-friendly no-code approach?’.
Is programming only about coding?
In fact it’s worth wondering: how much of a developer’s day is truly about coding? Meaning how much of your time as a developer is devoted to actually writing lines of code in a specific programming language? Of course it depends on what type of developer you are exactly (because this is just too much of an umbrella term to really refer to a single job!) but, still, lots of us programmers consider that carefully crafting your algorithm beforehand is necessary to producing a viable result.
In the article I talked about before, I mentioned how some computer science courses focus virtually entirely on theory and algorithms; to those teachers, programming should be agnostic to the language you end up using.
Although I believe some languages are better at conveying some theoretical concepts (for example, C is nice for memory allocation whereas Python is better for object-oriented programming), it’s true that you should be able to decouple “how your program works” from “how it’s written out”. Being a developer is not about remembering syntax by heart and spitting out lines of code — it’s about making the most of the technology at your disposal to solve problems and answer questions. It requires a specific mindset that cannot be “magically transmitted” via user-friendly interfaces.
This is why, to me, the no-code movement might be limited at some point: while having a UI-based programming tool can be nice (with drag-and-drop, colored buttons and pretty dropdowns), it still won’t teach you to structure and architect code as properly as you would with a solid formation in computer science.
I know not everyone codes the same; yet there are some conventions or standards that have slowly been put in place by the community. And these standards often have a history, associated debates, trials and errors… Things like the MVC model or class inheritance didn’t just appear one morning in the head of a lone programmer that decided to impose it on the rest: they were born out of multiple experiments! It’s part of a developer’s job to stay on her toes, keep tabs on the latest architectures and overall contribute to this global research.
In comparison, most no-code tools hide away this complexity and convince you that you don’t need to worry about architecture — it’s either so obvious you can just jump in, or already though of by others. In my opinion, this doesn’t make you a programmer, or at least not as good a programmer as one that thinks ahead and oversees the entire ins-and-outs of the solution.
Note: the funny thing is that the “speed-up” and “scability awe” you get from a no-code solution is usually most profitable to… day-to-day coders, that are familiar with the common struggle and can draft software in their head so that the no-code platform is then just a handy pencil!
How opinionated languages can be linked to the no-code philosophy
What are opinionated languages?
In the end, the distinction between opinionated and non-opinionated software is about control. Opinionated software believes that the language’s creators know better and can offer a fresh but specific view on the topic of programming and thus strongly suggest a “right way” of doing things to the user. Non-opinionated software lets you code more freely and gives you more power over your product.
It’s worth noting though that, with opinionated languages, the “right way” of tackling problems the creators of the language present you with can be worked around but it will often mean big headaches and unnecessary complexity.
It’s a bit like the well-known dilemma in the world of video games: linear versus open worlds. While the former are “reassuring” because they guide you every step of the way, they also constrain you to a specific response for all situations; the later let you run everywhere, discover hidden secrets or invent your own way of solving problems, but they require the player to actively work on building their own story.
Back to programming: in truth, how “nice” and “efficient” a language feels compared to another mostly depends on how well it matches the problem at hand (writing a web server in C is a nightmare and making a video game in R is clearly not what was initially intended with this language!). If your technology fits your problem perfectly, then opinionated software can be a breeze because it has ready-made solutions for your question.
Note: if you are familiar with Python backend frameworks, think of the difference between a lightweight package like Flask and a full-fledged creation tool like Django. Flask gives you the basic tools to make the backbone of your server but it doesn’t force you into a specific coding style and it doesn’t suggest particular technologies. On the other hand, Django is amazing for early prototyping, because you can get an entire project with a single line of command, but it immediately sets up a specific file tree, with a pre-ordained role for each piece of code (you need to write your models in the given models.py file for the app to work properly, for example).
An in-between that is endorsed by plenty of developers is the concept of “non-opinionated software with strict conventions”: instead of discouraging the user to do something by intrinsically making the language worse at it, you rather publish a set of rules and advise on how you think the language would be best used. If your language takes off and gathers a community, these rules will catch on and you will end up with an ecosystem that globally obeys by these constraints even though there is no actual technical limitation.
Another key feature of a programming language is whether or not it can be used to answer lots of questions, or rather focuses on one type of use case. Languages like PHP for web servers or R for data processing are mostly limited to their one usage; Python is often praised for being very versatile and coming as a user-friendly tool in many fields. Javascript is also extending its reach to more use cases than just browser dynamics with things like Node that offers a runtime engine or the numerous npm packages that provide developers with a gallery of nice extensions (resembling the Python pip packages).
How does this connect to the no-code movement?
I think that we can draw some parallels between the promises of a no-code solution and of a strongly opinionated programming language or package. Both aim at limiting the interaction surface of the user to lower complexity (and risks ;)) and both do it by giving the users well-crafted tools with a narrow purpose:
- in a no-code solution, one button will have one specific function
- in a strongly opinionated toolbox, a single command can be in charge of a complex yet single step of the process (e.g. Django’s
startprojectcommand line)
Moreover, most of the opinionated languages creators defend there being “harsh rules” by saying it helps gather a larger community: the point is not to limit the users because you fear them, it’s to provide a consistent and predictable coding framework. The Zen of Python has something along those lines with its famous mantra:
There should be one– and preferably only one –obvious way to do it.
In no-code tools… well, there’s usually only one way to do it!
So can the no-code movement bring everyone to the party: are developers over?
To be honest, to me the real question is about what we call a developer, what we call a maker and how we’d like to cut down the process of making software and today’s tech products. We probably have lots of definitions for all of these words and, in the end, an end-to-end development process can resemble so many things it doesn’t mean anything in itself.
If you think drag-and-dropping buttons on an interface will make you an expert programmer that knows all of the complex mechanics in a computer, then you’ll probably be disappointed and you should either lower your expectations or follow a more classical — but longer! — path with computer science studies. Conversely, if you’re interested in making a small phone app, on picking up on some very basic and universal programming concepts or if you’re a developer completely overworked, no-code tools can be a cool way of creating a working (sellable?) prototype.
There is a debate in the developers’ community whether no-code is a good or a bad thing — and whether people who say they “code visually” are somehow a “disgrace” to the coders themselves. But perhaps Ben Tossell, the founder of Makerpad, is right when he says:
People think that there is this big rivalry of code vs no code, but there isn’t (or shouldn’t be). We are both trying to create a product but our brains are wired differently
I still think that no-code tools, because they have some constraints and need to present a clear (and unique) path to the broader audience tend to produce similar results. Like with some strongly opinionated software, having one way to do things ends up creating very close-looking apps or websites… it may require a lot of effort to come up with a somewhat original design and it’s usually more about the underlying idea than actual personal UI customization. And seeing how fast UI design evolves, it might even give birth to a generation of apps that will soon look and feel outdated!
One final note: I think that producing actually usable code from a no-code solution requires the initial creators of the no-code tool to have full-control over every step of the production chain: if a user could mix several languages at various stages of their creative process, you would quickly end up with Frankenstein-like apps that might magically work for a while but will eventually crumble under the pressure of interdependencies. From a user point of view, it means that using a no-code tool to replace by-hand programming generally forces you to endorse and abandon yourselves to one and one creator only.
Although we should be aware of its limitations and not build our hopes up too high, the no-code movement is a fascinating and promising trend that has a lot of potential — I’m looking forward to seeing how it evolves in the near future!
References
- WordPress’s website: https://wordpress.org/
- IFTTT’s website: https://ifttt.com/
- App Maker’s website: https://developers.google.com/appmaker
- Honeycode’s website: https://www.honeycode.aws/
- Flow’s website: https://flow.microsoft.com/en-us/
- K. Kendall, “The Rise of the No-Code Movement” (https://www.sitepoint.com/the-rise-of-the-no-code-movement/), March 2020. [Online; last-access 06–09–2020]
- B. Clark, “How the “No Code” Movement Allows for Software Development by Non-Technical Entrepreneurs” (https://unemployable.com/podcast/no-code/), May 2020. [Online; last-access 06–09–2020]
- O. Ghiam, “How Makerpad guides businesses through the no code movement” (https://webflow.com/blog/no-code-movement), May 2020. [Online; last-access 06–09–2020]
- C. Winhall, “No-code movement: building startups without code” (https://makermag.com/no-code-movement/), December 2019. [Online; last-access 06–09–2020]
- Forbes, “Could the No Code Movement Put Programmers Out of a Job?” (https://medium.com/forbes/could-the-no-code-movement-put-programmers-out-of-a-job-cc0c7068b398), August 2020. [Online; last-access 06–09–2020]
- W. Larson, “Opinionated Programming Languages, The Huddled Masses, and Elitism” (https://lethain.com/opinionated-programming-languages-huddled-masses-a/), January 2008. [Online; last-access 06–09–2020]
- Woodward Academy, “Learning to Code in Primary School” (https://www.woodward.edu/blog/p/~board/beyondthegate/post/learning-to-code-in-primary-school) [Online; last-access 06–09–2020]
