This post was originally published by JP Hwang at Towards Data Science
Are you a Lego fan?
Lego was my first true obsession. Although I’m a recovering legoholic these days, I once had quite the collection that filled a gargantuan sack from which I could make anything. While I single-mindedly made some sort of spaceships, the point is that I could have made anything.
I have often read it said that the genius of Lego is its modular design. As in – any of its parts can be easily assembled into any other part. But I disagree. The real genius is in the integrity and strength of the connections between components.
Lego removes the engineering out of children’s construction projects. As an ex-engineer, I can tell you that this is no trivial feat. With Lego, the integrity and strength of the resulting structure is almost never an issue. They achieve this due to their parts’ high strength to weight ratio and high quality manufacturing leading to tight fits.
You simply don’t hear about Lego parts coming apart or of any Lego constructions failing under their own weight.
Building something with Lego isn’t about ensuring that the structure is sturdy, or finding the right type of fasteners/adhesives for the material.
It’s about letting your imagination fly, and conceptualising the output and finding the right pieces — Lego does the heavy lifting for you.
That is exactly what nocode tools are are doing for creators and businesses by taking the engineering out of app building. And for many of us, we need to consider what that means for the future of our workplaces and our work more broadly. Even if you are someone at a cutting edge of technology as a data scientist. We’ll come back to that, but many of you I am sure are wondering what the heck are nocode tools?
“Nocode” tools are those that allow its users to build software using plain-language options, visuals and other aids things that were traditionally built with code. You might have heard of examples like Zapier, Airtable, or Webflow.
While they have recently gained further momentum and popularity, they are hardly new (in fact, they’re extremely not new). They are not here to replace every programming language, or any, in fact.
Tools like Dreamweaver for web design and LabView/Simulink for engineers have been around for decades.
And let’s face it. Is Airtable fundamentally that different to MS Access? What about Webflow and Dreamweaver, or MS PowerApps and LabVIEW? Or are they just better iterations of these tools?
Also, it’s not currently possible to use nocode tools like a general programming language such as C++ or Python, and nor is it going to be. It’s not turtles (or nocode) all the way down, and there’s code somewhere. Nocode tools are ultimately abstractions of code, and as a result they’re going to have a larger overhead to develop.
So if nocode tools not new, and they’re not nearly as powerful as general programming languages, what is the innovation, and why is it such a big deal?
The secret isn’t its “nocode”, visual nature, although being able to learn a tool in a few days or hours rather than a few weeks certainly helps.
The killer features are the accessibility enabled by vastly improved bandwidths and compute power, and their ease of deployment, as the nocode platform abstracts all of that devops hell away for the general user.
There’s no need to make decisions or learn a whole new skillset about how to deploy it, what hosting services to use, whether to containerise it, ensuring the same environment/packages, remembering which ssh keys to use… you get the idea.
This might be child’s play for many developers, but most of us are not that, even those of us who do code. And for many it adds no value to know about this stuff. With nocode tools, once you build something, and it works, you deploy it by pressing a button.
The end users don’t care whether you built something on bubble.io by clicking buttons, or whether you built it in Python using Django and deployed it using Docker containers on AWS and the whole thing includes thousands and thousands of lines of code. It’s going to be the same for data scientists. Nocode data science tools are out there, and are only going to get better.
I think that nocode tools will help domain experts free themselves from dependency on coders. And for many of us, it should give us pause before making decisions about where to go next in our careers, and what skillsets to develop on the way there.
More specifically, every person who isn’t aspiring to be a full time programmer thinks really hard about whether they need to learn how to code. Instead, they should consider whether they know how to think systematically and solve problems.
Here is one example, and what got me thinking about what the maturation of nocode tools – niche, dedicated software packages.
I’ve seen my share of niche software packages; for HR, time management, legal, or regulatory functions. They often meet at least three out of the next four criteria: hard to use, obscenely expensive, rarely updated and sporting the looks of a 90’s website. Almost always, they’re also frustratingly not quite exactly what the users want or need.
The world of niche software is often a perfect example of imperfect marketplaces, dominated by a very limited number of suppliers serving a market who absolutely need something to keep the business churning along, and to make sure that they don’t get left behind.
Most people, regardless of whether they work in a finance department, law firm, or even engineering, would possess all three of inclination, skillset and time to build custom software to meet their exact needs. So the tyranny of imperfect (charitably), expensive software tools kept raging on.
Nocode tools are going to change most of that. It no longer makes sense to license software for thousands of dollars per seat per year, when you can hire someone, to do it yourself, or to purchase a similar app template for a few tens or even hundreds dollars.
I personally started with a blank AirTable project and built a legal matter management system with reminders in just days. I didn’t need to create a single line of code as such, but I did need to know what I wanted from my system, what type of data types each field was, which table was going to hold what data, and how they were related to each other.
In other words, I still needed to conceptualise the system that I wanted to build and how its components interacted. Just like Lego, you are building these systems using standard components. And in this paradigm, those of us with the ability to understand conceptualise the output, how each component works and and get from A (components) to B (system) will benefit.
The situation is going to be similar for many professionals.
Take a look at these templates for AirTable, or Webflow.
They cover a broad base of areas as well as providing a variety of templates within each category.
And as the tools become easier to use, the value of the skillset in using them also goes down.
It’s starting with relatively “old” technologies like e-commerce shop fronts (Shopify), web design (Webflow), databases (AirTable) and microservices (Zapier). But it’s going to permeate through all forms of technology.
The more general nocode platforms like Microsoft Power Apps is going to attempt to establish themselves as more general, enterprise app building ecosystems. Data science, as I mentioned, will not be an exception and tools from AWS, Azure and google as well as the smaller players bear this out already.
So where does that leave us? In a world where building apps, databases, data science models or shopfronts have little to no barrier to entry and a flat learning curve that resembles a gentle slope, the value is in systems thinking, and having a deeper understanding of your field. What long-standing problems of customers this app is going to solve, what your particular in-house database needs are, or what market to tackle with your e-store.
Ultimately, this is a good thing. Technological tools are just that – tools. They are not themselves solutions, but building blocks to create something greater.
But the changes to the tools will mean that we need to change with it, and acknowledge that the value of our skill sets will change accordingly. In a few years, people coding themselves might be looked at a little like those of us who build our own chairs. Admirable, but a rare thing to do and a hobbyist’s task rather than the most efficient overall.
A change is coming, and we all need to think about where we want to fit in.
This post was originally published by JP Hwang at Towards Data Science