This article is also available on Medium over here 🙂
A while ago, I wrote an article and participated in a podcast on no-code where I gave my point of view on the issues and the merits of this philosophy. And until very recently, I worked at a startup called Prevision.io that aims at delivering an AutoML platform. A small cross-examination of the two lead me to ponder upon the possible relationship these movements share, the goals and also the flaws they might have in common.
First things first: what are AutoML and no-code?
As explained for example in the Microsoft’s docs, “automated ML” is about reducing the time it takes data scientists to engineer and put in production their AI models. This concept is also linked to the democratisation of machine learning: most AutoML tools convey a message of user-friendliness, openness and overall they welcome everyone, even the so-called “citizen data scientists”, to join the party. The idea is basically that by having the computer take care of the iterative, repetitive and dull tasks in your machine learning pipeline (such as data cleaning, data packaging, models tweaking, apps deployment, etc.), you can focus on more meaningful steps and truly develop your potential – moreover, since a lot of the complex domain-specific notions are abstracted away by the system, you don’t need to be an AI expert to use it.
It’s worth noting that there are plenty of AutoML tools currently on the rise and that each can focus on different steps of the machine learning process for their automation (some cover the entire chain, but some are mainly for feature engineering, others for out-of-the-box models training, others for models in-production deployment…). Of course, the usual big players of computer science are joining in: Microsoft with the Azure ML cloud service, IBM with AutoAI or Google with their Cloud AutoML solution.
Similarly, the no-code philosophy preaches intuitive UIs and ready-to-use modular toolboxes because it wants to make programming a mainstream hobby that could be explored by as broad an audience as possible. In this day and age where everything around us is somehow controlled by computers and code, making coding skills mandatory for everyone is, in my opinion, a great and crucial idea. (For a more in-depth presentation of no-code, feel free to take a look at my previous article on the topic.)
This is why when I discovered the no-code movement last year, I immediately saw some ties with the AutoML trend. I’ll try and point out what common goals and flaws I believe these two philosophies share.
#1: Everyone’s invited!
Although each project has its own designated end users and addresses a particular group of people (following the rules of market segmentation), as I’ve said before no-code and AutoML tools are often presented as accessible to anyone.
This is because both these trends mostly rely on hiding the complexity linked to the job of programmer or data scientist under the hood. They do this by providing user-friendly interfaces, drag-and-drop or one-button actions instead of lines of code and out-of-the-box presets that have been neatly prepared to be as efficient as possible. This makes for an immersive and (hopefully) intuitive experience that even non-experts can dive into without the fear of gigantic concepts being lost on them.
Moreover, these tools are available to everyone because they are usually free (or cheap). This is mainly due to the development of cloud services. Now, companies can offer you powerful products without the hassle of installing them and configuring your computer for them. Instead, you’ll simply have an account (it may require a subscription, or have a free-trial period, or some other limitations if you’re not premium) and benefit from their services, their data storage, their computing power, their hardware… as a direct consumer. This model of “platform-as-a-service” (PaaS) (or even “software-as-a-service” [SaaS]) is becoming more and more of a norm nowadays: people are tired of stuffing their own computer with hundreds of apps – rather, they prefer to centralise everything to the cloud, be able to access it from everywhere and most importantly not have to worry about maintaining the system themselves. For companies, it usually helps reduce the cost because you can “group together” hundreds and hundreds of users, you only need to focus on one product that is released and distributed to everyone at the same time and you can put in place a shared architecture for all your clients.
Note: I’m simplifying things a bit here – if you’ve ever tested or checked out cloud solutions and in particular their various subscription offers, you’ll likely notice that it’s not truly the “same experience for all”. All those companies have learnt to provide you with some custom offers that require some flexibility on their part and prevent them from really having the exact same system for every user. However, at a large scale, most clients pick the basic offer and therefore enter the big pool of users that can all be catered for the same.
The PaaS and SaaS models, because they have companies use the same software for everyone, are also a good first step for “pay-as-you-go” systems: from the point of view of the user, this means that you will only be charged for the part of the software you actually use and the amount of time you spend on it. This is often very beneficial for the user compared to paying for a full-fledged solution you’ll never cover completely with your projects.
#2: Lightening the load for experts
Another important concept that I think applies both to AutoML and no-code solutions is prototyping. I mentioned this aspect of no-code in my previous article but I want to insist on the fact that, as a programmer and a data scientist, I don’t feel threaten by these tools.
Rather, I see an opportunity to automate tedious tasks and avoid repeating the same meaningless step on every new project. In the same way we now have CLIs (command-line interfaces) to quickly set up web projects (Vue CLI, create-react-app…), I like the idea of instantaneously “instantiating” a new ML project. To me, the advantage of these philosophies is that, for experts of the domain, it can help with quick sketches and rough prototypes so that you can actually focus on the underlying architecture of your software or AI process – this is your true skill and your true value to the project, it is best you spend your time doing this instead of cleaning up your data or re-styling yet another button, right?
#1: Everyone’s invited!
No, I’m not stuttering – I did list this as an advantage and a drawback! Because as tempting as it sounds, offering a service that can please each and everyone is, let’s be honest, close to impossible. I have a similar feeling about some huge Hollywood movies that want to earn as much money as possible by hitting the largest audience available and therefore come up with the most conventional, most standardised scenario possible: they don’t want to shock or hurt anyone, so they don’t actually touch anyone either.
With AutoML and no-code, this can also be an issue. Just like it can lower the personality of a movie and make it duller, uninteresting even, this wish to satisfy any type of audience with a tech tool often leads to:
- a growing set of features that are barely used (and hard to maintain) and are only interesting for one or two persons on Earth
- “in-between” UIs: my personal experience is that in these tools, UIs manage to be too standard and too complex at the same time! I mean that to attract as many people as possible, the designers rely on well-known mechanisms and intuitive layouts – this is good practise but it makes it hard to distinguish one platform from another since they are essentially laid out the same way. On the other hand, with this constant growth of features, you need to regularly add new buttons, dropdowns and menus which results in a thick UI that can be a headache to navigate.
- a constant need for documentation: this is a consequence of the previous items – since the product accumulates so much and has to pack it all in its interface, and since the core idea of those tools is to be usable by everyone, the creators need to dedicate a huge amount of time to writing documentation, making tutorials…
#2: Abstracting away too much?
Reducing complexity is, of course, a good idea! I’m all for letting specialists deploy my apps and do the top-notch load-balancing of services so the network doesn’t get cluttered with users. But as always, the question is: where do you stop?
The funny thing is that I feel like these past years, lots of jobs have grown to be more than the initial deal: everyone does their own bills, everyone needs to know how to manage a project, everyone has to be able to market their product… Suppose you join a company as a Python developer; you could end up doing some R&D on the side, writing a few articles, pitching in for software architecture advice or handling the dockerization of your own code. While this is not bad per se (I’m personally completely incapable of sticking to the exact same missions for more than a few months), it does beg the question: how are you supposed to know all of these skills? You’ve most probably had a formation as a Python developer and therefore felt entitled to apply for the job at first; but all this additional work was not expected.
Chances are if I told you a computer could take care of it for you, you’d be relieved – because it probably knows this stuff better than you, and you won’t have to wander into uncharted territories.
Now, let’s switch things around: if I told you a computer could completely automate the Python coding part and you only need to take care of the rest, what would you say?
I think this is one pitfall of no-code and AutoML solutions: they tend to overly simplify the core skills of the job. Sometimes it’s done well, sometimes not so much – nevertheless, a domain expert might feel like they’re robbed of their main purpose. And, as a newcomer to the field, you might have a hard time understanding the important concepts of the job if everything is hidden from you, so you’ll never truly know the ins and outs of the process you’re doing every day with this great automated tool – you’ll only have a surface (and thus possibly biased) knowledge of the domain.
This abstraction can even raise security concerns: since you are required to upload and store your data on the service, you may be concerned it is misused by the owners of the service; and you are subjected to the problem of “vendor lock-in”: once you’ve chosen your no-code or AutoML platform, you’re usually stuck with it until the end. You’re dependent on their solution and forced to obey their rules, to follow their choices… and to hope they don’t crash down the road!
#3: Standardisation of everything
Because [no-code is] a higher level of abstraction, it will be limiting in some ways. You won’t have the same flexibility as code.
Once again, pleasing everyone limits your choices and forces you to focus on a set of commonly used elements or features. You don’t spend extra-time on original ideas or components, you first (and ultimately only) produce mainstream tools you’re sure everyone will like and use. You also package your offers in a standard way so everyone feels at home and can navigate your website easily. And you offer efficient solutions for usual cases… but lack the customisation needed for edge cases (like particular database scaling, domain-specific security regulations, etc.).
In fact, the “free and cheap” aspect of those platforms I praised earlier is true only to a certain degree – more often than not, any personalisation will require you to pay; sometimes, this can even outweigh the cost of a “traditional” manually developed solution.
Maybe this standardisation will also inhibit the creativity of some and block original ideas from coming out. If everyone uses the same no-code solution with the same visual components, it will be hard to get creative UIs in the resulting apps; if everyone takes advantage of the same auto-feature engineering modules and pre-trained models, perhaps machine learning will start going around in circles and only deliver correct-but-average predictions, with no new groundbreaking processing methods.
Both AutoML and no-code are fascinating trends that could have a large impact on the community of developers and data scientists. Though it might seem scary to some and carry on the well-known fear of “computers stealing our jobs”, I don’t think we should work in opposition to those new philosophies. On the contrary, it would be more interesting for programmers as well as no-coders if these tools were used as a middle-ground, a new medium of sorts to have non-specialists exchange with experts.
I’m deeply convinced that bringing more people in can be amazing: having new points of view, new ways of thinking, new cultural backgrounds in the world of dev could help unexpected ideas bloom; sharing our knowledge of code with others could help raise the global awareness of the population on the use of technology in our modern societies which is essential today. Perhaps it is time we coders and AI experts jump on the bandwagon and join the no-code/AutoML trends, if only to discuss with unlooked-for counterparts?
- Prevision.io’s website: https://prevision.io/
- Microsoft Azure ML’s website: https://azure.microsoft.com/en-gb/services/machine-learning/
- IBM AutoAI’s website: https://www.ibm.com/cloud/watson-studio/autoai
- Google Cloud AutoML’s website: https://cloud.google.com/automl
- Bubble’s website: https://bubble.io/
- Vue CLI’s website: https://cli.vuejs.org/
- create-react-app’s Github: https://github.com/facebook/create-react-app
- Microsoft Docs, “What is automated machine learning (AutoML)?” (https://docs.microsoft.com/en-us/azure/machine-learning/concept-automated-ml), October 2020. [Online; last-access 22-02-2021]
- IBM Cloud Education, “PaaS (Platform-as-a-Service)” (https://www.ibm.com/cloud/learn/paas), October 2019. [Online; last-access 22-02-2021]
- K. Terziev, “Will No-code Development Platforms Kill Coding?” (https://codecoda.com/en/blog/entry/will-no-code-development-platforms-kill-coding), October 2020. [Online; last-access 22-02-2021]
- I. Wikimedia Foundation, “Market segmentation” (https://en.wikipedia.org/wiki/Market_segmentation), January 2021. [Online; last-access 22-02-2021]