A couple of days ago I came across a LinkedIn post detailing the design process that a particular agency had used when developing marketing graphics for a client. A great post to read along to, especially when trying to understand the real value that designers bring to companies, and the scientific approach being used to introduce creativity. However, one of the commenters on the post made a banal comment that tried to discredit the work involved as part of the initial design was built on Canva for speed. Discrediting the work completely as Canva should and would never be used by designers as it cheapens the work. That the tool itself was inherently dictating who or who could not be a designer, and the years of training, theory, and practice was of waste.
That comment got me thinking, if a developer were to use NoCode tools, would that mean that they are no longer a developer? Could you ever be a NoCode developer? What is a developer actually?
These sorts of questions are not new. Any change, especially one that impacts a job or profession, illicits the same emotions. The term “driver” was first used to refer to the driving of working animals. The word itself means to compel movement, or to bring about movement with physical force. With the adoption of automobiles, we now use this to describe someone driving a car, or one who makes it their profession to drive a car. We have many different forms of drivers, including chauffeurs, bus drivers, and even professional race car drivers. With level 5 self driving cars around the horizon, this word may change to not refer to a person at all.
As new technologies and methods were introduced, the word itself transformed to fit this meanings. However, the intention remains the same - a driver compels movement. So how does this fit into our modern understanding of a developer?
What is a developer?
At it’s root a developer is someone who creates or improves something. To create value or increase value as mostly understood in modern economies. These developers could be engaged in the work of creating software, digital products, or even real estate projects. However, the word itself has become more of a sense of identity, with domain over a persona. You may have an image in your head already of the stereotypical tech bro, or FAANG engineer. Someone who not only writes code, but lives code. Going so far counter culture that that the lack of supposed business culture is a culture in and of itself.
This image and view is a wholly unfair one. Developers should not be sandboxed into a particular stereotype. While this may be common stereotype, it doesn't do justice to the hours of dedicated building and education gone in to learning something complex and intricate. It doesn't speak towards the profession pushing the boundaries of how we live and work.
Developers come in many different shapes and forms. Building the modern digital future as we know it today. Solving problems and creating value, that’s what developers do and who they best represent. And in this respect, yes, NoCode developers are developers. They do not write code but they do solve problems. It is however important to understand the difference.
What is NoCode development
NoCode development is the practice of building digital products and solutions without writing code. Rather, NoCode uses visual editors and pre packaged code elements to create “building blocks”, that when placed together can create powerful websites, applications, automations, and more. This doesn’t mean that code isn’t being used, it’s just that the code is being generated in the background. With it’s visual first methodology, NoCode allows users and developers to create products quickly, often times an order of magnitude faster than with traditional code.
How does NoCode development differ from traditional development
With NoCode being a fast growing methodology in development, it’s important to understand how it differs from traditional development. That is, traditional development that relies on writing code.
As mentioned, NoCode tools use visual editors to analogize what the code in the background is doing when placed together. This can be in the form of a visual editor that allows users to drag and drop components together onto the screen of a mobile phone, to display creating a mobile application - as you see with the Glide editor. You could be editing a website on a canvas, like you see with Softr, or be working with a spreadsheet like database on Airtable. Or perhaps drawing automation linkages of different services together on a big whiteboard like canvas, as you’d see on Make.
While writing traditional code seems like it wouldn’t be a visual practice, this isn’t exactly the case. Depending on the circumstance, front end developers use IDEs, like VS Code, that display what they are writing as they are writing it. This isn’t always available, especially if the work being done involves back end systems - like server side scripting or manipulating infrastructure. In these cases, visualizations through process building (mockups, process flows, and reporting) are used.
While to the uninitiated it would seem as though all written code is completely custom, this is far from the truth. Similar to NoCode developers using pre built code packages in the form of blocks to build products, developers writing code often do the same. This comes from using code repositories, open source or otherwise, which contain packages of prebuilt code commands that can be called upon. Often times, however, developers working with code have a greater degree of flexibility with these packages, to run them in ways that best suit their needs, than NoCode developers do.
While at it’s heart both Code developers and NoCode developers do similar things, solving problems with logic, the maturity of the tools are not the same. While NoCode has existed in some form for decades (read more here!), for practical development it’s still in it’s infancy. Strong practices around versioning, documentation, translatability, and even education are being explored. Benoit and NcScale, as well as many others, are working on tools to address these problems, however for some of the most complex of use cases, custom code will always win out.
When does NoCode and Custom Code make sense
With two different options to solve similar problems, which methodology should you use to develop your products or tools?
- Speed - NoCode development has been shown to reduce development cycles by roughly 3 to 5 times. With this, NoCode is best suited towards rapid prototyping, testing new ideas on a market, or creating internal tools to increase team productivity.
- Affordability - With reduced development times, and a smaller barrier to entry, comes reduced cost. While most NoCode tools run on SaaS models charging monthly fees, these costs usually represent a minuscule proportion of a traditional developers salary.
- Easier to communicate - As NoCode runs on a visual first methodology, it drastically reduces barriers to entry to build and also communicate what is happening. Mockups can be shown directly on a phone, or with it’s speed, entire products can be developed in hours for live demos. Additionally, if your team is non-technical , you might find yourself saving a lot of time that would have been used creating tools or translating your activities because it doesn’t make sense for them to learn to understand your code.
- Scalable - Contrary to popular belief NoCode can be a scalable activity creating scalable solutions. Lambda school, an online teaching program that taught it’s students how to code, used NoCode to build out their platform. It wasn’t until they had raised over 120 million dollars of funding, and had tens of thousands of active users that they started to see cracks in their NoCode foundations.
- Completely custom use cases - Custom code bases are great when the use cases for them are completely custom. Especially in new environments where NoCode alternatives don't currently exist.
- When code needs to be proprietary - If Code is the secret sauce of the business, then it’s best for it to be custom. You can’t patent NoCode after all - it ultimately isn’t your code.
- When that’s what you’re familiar with - It’s better to work with what you know. So if you know how to code, do it! It’s always better to have something released than not, so if you or your team know how to code, you will find it easier to continue to code. Doubly so if your customers and your business is meant to be technical.
- If it fits better with your existing stack - In a similar vein, if your business or projects already use code, then often times it doesn’t make sense to translate all of those projects into NoCode. Integration and code streamlining can make it easier for you to work with what you have, and lead to a better experience for your users and customers.
Will NoCode make developers redundant
No. Absolutely not. NoCode will not make traditional developers and custom code redundant. In fact, I can only see NoCode leading towards a greater stream of traditional code projects, and a lot more people learning how to code. What NoCode does great, and what it has always done in all of it’s forms, is to reduce barriers. It makes building projects more accessible to non technical builders, and gets them more engaged in what they are building. And as those builders are building, more companies and activities will become digital. With that brings scale, custom requirements, and custom code.
Just as rapid prototyping didn’t make engineers obsolete, NoCode won’t make traditional developers go away. Tools are tools, they do not define who or what someone is. So LinkedIn commenter, just because you use Canva doesn’t mean that you can’t be a designer, and just because you use NoCode doesn’t mean that you can’t be a developer.
NoCode development at JMP Studios
If you’re looking for NoCode development for yourself or your company, check out JMP Studios at JMPStudios.xyz where we develop Unlimited NoCode Applications, websites, and automations for one monthly subscription.