No code for nocode (1)

This post is part of a series:

Summary of the series

• Nocode solves a business problem rather than a technical problem: It can be understood as a form of declarative programming
• Instead of saving the declarative programs in a database, we could use git repos and our existing dev-toolset
• We can build on top of existing data formats and create mappings between declarative and imperative programming
• Different non-developers can get different shards of declarative data. That means: Custom nocode-tools for our team mates!
• We'll look at a proof of concept with a popular tech stack. It shows that the concept works, what its possibilities and its boundaries are

The promise

"No coding needed" - does that mean thousands of devs will loose their jobs and dev.to can close their virtual doors?

Yes ;) All your fears will come true, the same way your past selves lost their jobs when you created that automation-script you're now a little proud of. But why was your automation-script so useful in the first place?

• Did nobody like to do that task?
• Your team mate often asked for A, B and C, and your script takes paramA, paramB, paramC as input?
• Three different colleagues tried the task before, with three different results - and you had to combine their work?
• It has run so often that you're thinking about version 2

Productivity

All of the above points don't have anything to do with code in the script. Code might have been important to build it, but the value your script creates for your team and organisation comes from something else. Your script touches the work of others, and makes their day a bit easier. This lets all of you work better together, but only if you're not on vacation. When your team mate sends you an email with A, B and C - your email-inbox is the current nocode-interface to that script.

The emails keep coming

Let's say word-of-mouth makes your script really popular, but now you get emails with B, C, D and E - and you've never heard of D and E, but the colleagues from the other department talk about it all the time. Your team mate has the Domain knowledge how D and E can be combined to form A. Wouldn't it be nice if your team mate could help improve the problems with your inbox filling up, and combine D and E?

Performance issues, outside computers

From a productivity perspective, once one bottleneck is fixed, another one needs fixing. What happened with your script, your colleagues and your team mate is the normal way an organization progresses. From a business perspective though, the power to progress is important. This power in the hands of more employees, that's what "Nocode" then sounds like.

Data about common problems

The problems that nocode-tools are currently trying to fix are mostly the ones that have existed across different industries. For example building web-interfaces. Centering elements in CSS? Just one click inside a nocode-tool.

Where does your data go in which format?

Now the nocode-tools may save element.centered = true somewhere in a database, somewhere in the cloud. Another one will save UIComponent.alignment = 'center' somewhere else, and both tools probably use a similar center-button. So there exists an unwritten industry-standard saying how a center-button should look like. However, there isn't an industry standard saying how or where to save that information.

Declaring what the program should do

"Alexa, center that element" is something we can't universally do because every tool implements the center-button-click in its own way. This is different when there is a commonly understood format for "centered-ness". How the button-click is turned into CSS or mobile elements is less important than what that button does.

Closed source and interfaces

With nocode-platforms, the declarative part of our program is hidden away in a database in a proprietary format. This is actually good in the Genesis-phase of tool-development, because changes happen often and code and interfaces stabilize slowly. The more mature a tool becomes, the more it has to stabilize though. For example a company working on a voice-plugin needs interfaces to "just work".

De-facto standards

At some point a tool reaches a point where it's a de-facto standard, where people say "Excel" instead of "spreadsheet". Excel's interfaces can't change that much any more, spreadsheet-tools are rather similar. This process is called commoditization. New tools based on spreadsheets can change a lot though, and a lot of nocode-tools actually make use of spreadsheets. How reliable can a proprietary de-facto standard be?

Remember Flash and Actionscript?

Flash offered something that was not possible on the web at the time. Nowadays, animations, video, audio and webcam-access seem normal, but then it was a substantial improvement. More importantly, in the visual editor it was quicker to design and animate than in code, and in the code-editor it was easier to create the behaviour.

What made it popular was the interface between designers and coders. What made it unpopular were security-issues, performance-issues and web-standards catching up. Although many were affected, there was only one company that could really fix Flash. When major parts were open sourced it was already too late, Flash was on the decline. Code-bases had to be rewritten rather than migrated because the custom tooling worked well with Flash, but not "the outside world". However, the source code for Flash-programs was saved in the file system. If a nocode-platform goes down it's up to the platform what happens with the nocode-programs it hosts.
Worst-case scenario: No more code.

We gladly have better open standards now, and the nocode-movement lets people solve more problems. If the nocode approach leads to many proprietary standards, that means integrators and customizers can get more business. Skillsets aren't as easily transferable between tools, which leads to rather closed communities around those standards.

Self-hosted vs cloud

The risk of a platform failing is lower with tools that can run both in the cloud, on-premise and locally. WordPress would be an example where anything "nocode" can be easily migrated. This is part of the design, thanks to established data formats. To migrate a mature data format would take quite an investment: The efforts for the Gutenberg editor from WordPress can give an indicator for that.

Open data formats

Open, mature data formats have a steeper learning curve, but it pays off to develop against established interfaces. Our IDEs are already one step closer to nocode-environments, especially if we count in extensions:

• Frontend and backend devs interface with OpenAPI/graphql schemas
• devs and devops interface with docker-compose files/kubernetes
• devs and data/analytics interface with SQL queries
• Pull requests get synced into JIRA for Project managers

So maybe the VS Code language server is a good starting point for the next low/nocode-tool. Asking

"What part of my IDE might be interesting for my colleagues?"

Also, when data formats are open and limited in their scope, it seems that dev-communities form around them. When the code fits into a stackoverflow-like answer, I guess it's easier to help each other.

To code or not to code, is this really a question?

All in all with nocode, we developers won't lose our jobs and Dev.to won't have to close their virtual doors either. There will be more problems to solve. Let's welcome new problem solvers, whether they're coders, hackers, software developers or the new citizen developers, and improve interfaces together.