Some seem to supplement developers (eg: retool) and some empower non-engineers to be able to build websites/apps/integrations without necessarily having a developer in the loop (eg: shopify/zapier/airtable).
What do you think about this movement? Clearly these apps/platforms enable non-developers to solve a bunch of problems which would otherwise need a software engineer. Is this a paradigm shift?
I recognize COBOL may not seem like "no-code", but that's just because "no-code" is a stupid label. "No-code" doesn't mean "no code" just like "serverless" still runs on a server.
I would say the main problem with the no-code hype is the idea that it is a leader. It is not. It is a follower. "Normal" code goes out, hammers things out over the course of literally decades, and then, when it has finally settled what the best couple of ways to do something is, it's finally time for the "no code" solutions to come in and systematize that for a larger audience. Nothing wrong with that. Power to the people and all that.
It just goes wrong when no-code advocates put the cart in front of the horse and make grandiose claims about replacing all developers or something. That's not the direction the stream flows in. No-code can't operate without the "normal" developers doing immense amounts of work charting the territory and building the infrastructure to get there. There is no chance of them displacing "normal" software developers; they are structurally incapable of it. Woe unto the no-code startup that doesn't understanding this dynamic, and foolishly tries.
Excel allows non-coders to do many useful things, and provides a relatively gentle on-ramp to actual code via formulas. If you take that on-ramp and keep going, towards VBA and add-ins and other pieces of Microsoft technology, you might wind up becoming a full-time software developer, leaving Excel behind and using “real” tools.
Now, there’s a happy path and an unhappy path here.
The happy path is that you use Excel for what it’s good at, but recognize when you are operating at its limits, and at that point pivot into “real” software engineering tools.
The unhappy path is that you stick with Excel too long and become mired in the world of VBA and advanced formulas and attempts at shared workbooks, and build pseudo-database application-contraptions.
No-code can be like that early Excel usage: it can grant some limited but useful powers to non-developers. But no-code can also evolve to become like those contorted, unmaintainable spreadsheet monstrosities that stretch the technology far beyond the point where some “real” software engineering would have been the right answer.
Short version: use the right tool for the job.
Having said that, I have been working with Microsoft PowerAutomate for the past 1.5 years and while it has saved a lot of time and been overall a good experience, there are times when the no code/low code gets in the way and I wish I could just "drop into code" to get something done. Examples are things like data validation. This technology is not going to replace coding, the paradigm shift is really happening for people in the marketing and sales operations parts of the business. For these folks, this tech is life changing. In a lot of ways, this tech felt like when you try a new framework in your language of choice; at first it's super easy and you get hyped, and then you hit a requirement where the nocode/lowcode environment really gets in the way.
1 hour before you Ask HN: Do you like the term 'nocode'? https://news.ycombinator.com/item?id=29187754
2 days ago Ask HN: No Code GUI Tools? https://news.ycombinator.com/item?id=29160858
3 months ago Ask HN: Is there any future for low-code/no-code development? https://news.ycombinator.com/item?id=28150056
4 months ago Ask HN: Anyone built a business with no-code tools? https://news.ycombinator.com/item?id=27593073
3 months ago Ask HN: What do you think of Producthunt's obsession with no-code solutions? https://news.ycombinator.com/item?id=28194430
It was the best I've ever seen balance of managing complexity, yet letting you write code when you needed to.
The C++ version was nowhere near as god, it generated a ton of templates and things that just weren't necessary in Pascal.
Since then everything is expected to work across the internet, through a web browser, web server, etc. It'll never be as simple and effective as it was.
Languages and tools are user interfaces, and any time you have many different jobs to be done by many different people with many different contexts, it is natural to develop several different interfaces for what may appear to be the same work.
Thus, low-code and no-code. But!
Programming is more than just coding. It’s also all the activities AROUND the coding, including things like reviewing code before it is deployed, version control, reverting code, testing code, automated tests that also serve as DSLs for describing the behaviour of code, &c.
Robust no-code or low-code systems also need to address the needs that the systems and tooling that live around high-code serve.
They don’t need to do these things the exact same way, but it’s a Chesterton’s Fence situation: We shouldn’t just ignore those other systems, we should figure out why they exist and make sure that either we know those needs no longer exist, or address them another way.
https://raganwald.com/2012/01/08/duck-programming.html
Discussion around the original post:
As an example our Art Director built this without any programmer assistance or writing a line of code. Just taking a basic multiplayer FPS game then grabbing components we had already made and jamming them together to get parts working: https://twitter.com/voxeleus/status/1437754413813207047/vide...
You can further see this in many creative games or games with modding tools where players put together complex behavior without using a line of code. Right up to things like Minecraft Redstone which is really an esoteric, spatial programming language. But crucially doesn't feel much like programming at all.
I think there's a lot to be taken from the game space for people trying to build no-code tools. Particularly in that you're not trying to remove a programmer but empower non-programmers in ways that suit them.
My view is that, indeed, the general no-code category represents a paradigm shift in the truest sense. That is, it is not going to replace anything we currently use software engineering for, except at the very edges. This is pretty obvious to anyone who understands software and the complexity inherent in building custom things. Rather, it will enable a massive new category of software to be built, where presently it is uneconomical to do so.
Think simple tools, sometimes throwaway tools only needed for a few weeks, tools specific to each new project - things currently implemented with whiteboards and sticky notes that would clearly be better as digital tools in all sorts of ways - and indeed increasingly essential as the assumption that everyone is in the same office gets less true.
This stuff is typically quite straightforward but requires deep domain context that'd be really difficult to translate into a spec, and way too expensive anyway to justify hiring engineers to build, but it can now just be done directly by the domain experts themselves who need not necessarily be technical.
This category is simply massive - think of the number of such tools that could be useful in even a single given business if they were simple and cheap to create. Now multiply that by every business.
If you're convinced / intrigued by any of what I've said, by the way, we are hiring. So let's chat about it more! Email is in my profile :-)
Like Excel, people made applications with it. Unlike Excel, it created a server product in the mid-eighties that allowed it to become an IT platform. Small business owners who had hacked up a Helix database to help with invoicing were able to extend the function to the entire organization without ever using a keyboard for anything except typing label names on reports. All drag-and-drop icon stuff.
Fast forward twenty-five years. Today the applications have grown and grown and grown. The owners who created them are old, prosperous and tired of screwing around with it. Also, Helix is no longer well supported. These people are screwed.
I consult for a few companies that use it. These apps are exact replicas of the brain process of the owner that made them without a single structured thought in sight. Even if Helix were a healthy platform, the apps are largely unmaintainable.
They are also so complicated and so deeply integrated into the companies that they represent a horrible threat. They can't easily adapt to the modern world and will cost millions to replace.
Which is to say, these no-code systems encourage amateurs to reach too far. I advise people against them.
The wrong question is: (most/many) people cannot program because it is difficult to type the right things in, so let us remove typing.
The right question should be: how can we more efficiently develop software?
No-one would ever think to start a no-write movement because people cannot write properly. We instead teach everyone to write starting from the first grade, and we build tools to help them write better (dictionaries, word processors, spell checkers).
For programming, we should also concentrate on building tools (like the awesome IDEs of today) that makes developing software more efficient. Some of the efficiency can be had by no-code (i.e., Delphi-style forms), some can be had by improvements to technology (code completion), some can be had by improved language design. We should also invest more in programming education.
Low/no code DSLs are also good (think of Excel).
But I am skeptical of general purpose no-code: if it's Turing-complete, it's just a programming language in disguise.
You want to handle this very specific edge case? With code, there is certainly a way to do this. It may take days, it may add unreasonable complexity. Nevertheless, someone (yourself?) will ask that this kinda insignificant edge case is properly handled. And won’t take no for an answer.
With a (too) limited « no code » tool, maybe there really is no way to handle the edge case (or it would require code in a context that forbids it). Management (or yourself!) has no way to make someone fix this, and can just give up. Soon enough, there is no problem. Finally, you can live with the unhandled edge case! Ok, you’ll just brief users. Ok they’ll learn by themselves that they shouldn’t do this.
So sometimes, « no code » tools can’t solve a problem. Then the problem simply disappear. It helps with finding a 80-20, something good enough. Everyone can be focused on more important stuff.
Those who promote 'no code' solutions always seem to think that just because one does not edit with a text editor that there is no need to design the solution or to debug it.
One is still developing, just using different tools.
For some subset of problems it might indeed enable someone who is not a programmer to create a solution just as Excel enabled millions of people to do just that. Unfortunately one usually finds a little later that the solution has the shape of the tools used to create it, that because the tool could do something in a certain way that is the way that is chosen rather than choosing the tool to fit the intended solution.
You end up with people creating databases in Excel because Excel is what they had.
I previously was supporting a company integration with Appian (building the AWS/Webservices integrating the two halves), which bills itself as a Low Code platform for Business Process Management. And their hello world example kind of worked fine for getting "a business person" to "write code". So the idea was they get these business people to write code instead of developers. But the problem with this platform was that we had to eventually get full time software developers (so no cost savings there, but also had the issue of these devs were now niche developers and not learning broader skill sets). Because their graphical development didn't cut it, so they had to drop down into their code proprietary DSL. Then the actual platform was a mess of no cicd, bad disaster recovery, bad monitoring, bad everything. It would have been cheaper and easier to literally just write a business process management from scratch in whatever language we wanted.
tl;dr No code, low code, graphical programming is a fad.
The "no-code" desire has been around for decades -- just using different terms. E.g. in 1980s and 1990s, a common phrase for new tools that didn't require programmers was "self-service" ... like Crystal Reports software for "self-service reports without programming".
To put it in perspective, consider that Microsoft Excel is a "no-code" tool. In the old days before desktop computers, if a business person wanted to look at a report of sales amounts grouped a different way, he would ask the COBOL programmers in the IT department for a "change request" and they'd do the following:
- "code" new punch cards for the mainframe: https://www.google.com/search?q=mainframe+punch+cards&source...
- load of magnetic tapes (each held about 40 megabytes) of the sales data: https://www.google.com/search?q=mainframe+9-track+tape&sourc...
- get a new report on greenbar paper: https://www.google.com/search?q=greenbar+paper&source=lnms&t...
Now, any office worker can do the above with a "no-code" tool like MS Excel with pivot tables, filters, etc. Even though Excel eliminates a lot of coding work, the demand for programmers keeps going up. No matter what "no-code" tool is invented, the world keeps inventing new tasks for human programmers to do that today's no-code tool can't do. There's always a delta in capabilities.
Some time (not long) ago I was working remotely on some software that was driven by an API on a remote server maintained by some folks in a different country. A long way from me.
Cutting a long story short I realised that the lack of control over the server was because they really did not know how it worked, or how to fix it or diagnose issues their server was having.
It was a laraval/MS-SQL system built from building blocks supplied by Microsoft. They wired all the blocks together in a GUI and look! It works!
* Putting images into a UU-encoded text field worked for images <7MB... The actual images the customers want are >10MB
* Low levels of activity it was reliable. Under load it randomly dropped sessions.
* They did not seem to know what logging was, or how to use it. I was supplying them with problem reports, carefully noting the time - and getting ghosted. I realised they had no way of knowing what their software was doing, or did. They could only set it up to do what they hoped.
* The stored times as wall clock time strings "2019-02-12T03:02:12.123" No time zone included. Time series data worth a lot of money. "What happens when daylight savings repeats an hour or skips one?" I asked. No answer. This infected the whole system. I spent a lot of time fighting dates, and was that in the past? Future? Is that supposed to be now?
Back in 1997 we had more reliable, and higher quality software, on a telehoused 486 Apache/Perl/Postgres system. But we compiled it from source and edited the configuration files by hand.
"No code" might be OK for Aunties cookie recipes, but for building infrastructure it is rot
You may ask why then I don't write my own OS/IDE/Database/etc., well I'd love to but sadly I don't have the skills. I only do things within the boundary of my skills.
Sorry, ownership is No.1 issue for me.
It's not a movement, more like a mini-trend based on rediscovery of an old idea. At least not a pure investor duping like "metaverse".
> Clearly these apps/platforms enable non-developers to solve a bunch of problems which would otherwise need a software engineer. Is this a paradigm shift?
If it is, it happened in the last century and many times since then already. You could still hype it up for a new domain to grab some investor money, I guess.
https://pubs.acs.org/doi/pdf/10.1021/ie50587a038
She's talking about the difference between "programmer" (one who designs logic and processes) from "coder" (one who converts those processes to "codes" - i.e. assembly) and how compilers have the potential to eliminate the need for "coders"
I'm tickled by the (IMO) obvious parallels that have just moved up a few levels in complexity us who use text editors to write programs are often supporting configurable logic for someone downstream who can get work done with less complexity using simpler, more accessible tools.
Excel is the archetypal success-story, perhaps. It is ill-suited as a general purpose programming language, but as a language for arithmetic operations on data it... excels.
The same is true of Airtable and Zapier. They introduce new, simple abstractions for data, and for automation.
Disclosure: I'm the founder of a no-code startup in the browser automation space. I rationalise what we do as 'introducing high-level abstractions in a visual DSL'. You won't see that description in investor pitches. No-code products are just high-level programming languages.
If you pick the correct abstractions, working this way is actually faster than coding for the bulk of use-cases, whilst making edge-cases hard to deal with. For those, coding is inevitable.
On the other hand, is full scale development, either in-house or outsourced. This is only doable for projects that are ~$50k and up, even if you go with cheap offshore developers.
So there's this gap from ~$5000 to $50,000 where if that's all you can afford, you just can't justify the project. In theory that's where the "low code" tools should fit, but so far, I have never seen it work out like that.
I'm a huge fan of Plasmic so far, I've tried to make frontend react sites and they don't look as nice as what I'm able to achieve with what I can only call a "website builder" tool.
My goal is to customize the CMS and use it as an API for a separate frontend site. JAMStack is the future... I don't think there is anything specifically 'no-code' about it but I'm suggesting two tools here that let you do no-code and also have nice doorhandles to let you get under the hood. I think that last part is key.
In that case, it violates laws of thermodynamics, in the "no code" case, it violates Information Theory.
The entire process of coding is about translating requirements into machine executable programs. The requirements cannot be condensed below a certain threshold and that's where the 'no code' promise fails. You can move around blocks of shapes but in the end they must represent the same amount of information and it just resembles code.
Obviously, there are use cases for these type of systems. Many businesses only need a simple website, and there are a lot of problems out there where an off the shelf solution will suffice. However, I doubt no-code is going to make any meaningful impact on software development. The world is full of problems too complicated to solve with off the shelf solutions, and those problems will need a programmer to write some code.
Do you know how many people's jobs today are "this person is really good with excel, so we can hold on hiring a dev team and data scientist"? Probably millions. They're everywhere. I met dozens of them hidden away in Amazon warehouses during my career there. And Excel is the ultimate 'no-code' tool, pinnacle of the industry.
And yet the developers, we're all still here. Frankly, there's more of us. Because what really happens when you don't need developers to do the simple stuff is that developers can instead focus on the hard, higher-value problems, that a no-code solution can't do for you. More gets done, more value gets created.
There's always talk that eventually, we'll reach the end of the runway and the no-code will replace are large portion of us. I don't think we're anywhere near that. So bring on your no-code products, I say.
Fred Brooks essay "No Silver Bullet"
These platforms are great at making use of bottom tier devs quite effectively. They're a resource amplifier, when you don't have the cash to hire better devs. Hire a few devs to create the custom controls, actions, etc.. and have a boat load of juniors implement the requirements. Most of these folk haven't picked up a new language since college, and don't incorporate coding into their lives. These individuals have value, but often create more problems due to their lack of skill and/or experience. In a low/no code environment, you can better ensure that they're on rails.
The issues we're encountering is the pricing model, and it's most likely we'll end up going with Microsoft's because of the existing contracts. ServiceNow for all it's strengths really shoots itself in the foot with pricing. A product like this benefits from any "power" user being able to implement their own internal workflows, but ServiceNow charges per dev. So they're handicapping themselves. But someone will figure out all the pieces, it's inevitable.
As a means to solve boring, repetitive, uninspired development, it's great, and it'll be the future in the way that SquareSpace and Wix ate into front end presence sites...
And honestly, if you aren't a great developer, I suspect the rails would make you feel a lot better.
This won't take any jobs from anyone likely reading this. HN frequently has a blind spot for that vast majority of enterprise development. It's not sexy, but it makes up more developers than the Silicon Valley crowd by magnitudes. And most of them would fail a Fizz Buzz. With no code, I can make use of those resources.
Here's my take, quoted from my thread:
I've slowly started appreciating the nocode / low-code movement. At first: I thought it was a lazy person's dream, but more and more I realize a lot of the low hanging fruit that you can do with code has been done and there's little left to make. I mean, why bother re-invent the wheel right? So now I just leverage software made by other people typically GUIs / point-and-click tools and a bunch of online services to automate burdensome tasks.
I still write simple one-liner helper scripts in my free time though, typically userscripts that I place into Tampermonkey/Violentmonkey to automate a bunch of stuff and make the web more accessible. I call this 'low code' so I'm not entirely reliant on GUIs.
What's your thought on the movement? Do you like the term 'nocode'?
I think a lot of the problem is the endless hype and over-promising by marketing and sales people.
No-Code / Low-Code / Full-Code is a false trichotomy anyway. There's no reason why visual coding needs to be any more restricted than the real deal.
It's all just one big usability problem. We'll continue to develop software pretending we're running 80 character wide terminals for awhile, but I believe this will change someday.
Tools like Enso, or the Elm debugger already show how much better things are with instant, actionable feedback, even on "real" languages. Then you remember Smalltalk and HyperCard existed in the 80s and you wonder how it all went so wrong.
Just: SQL tables, prettified CRUD on those SQL tables on the frontend (with R/W permissions per user on tables), and reports (either on-the-fly or SQL queries run on a cron schedule).
If you can combine big Lego blocks into something useful, that sounds great.
If you need more fine-grained control, you need smaller blocks.
And that is the spectrum from assembly to higher level languages to platforms to libraries to frameworks to low-code tools to no-code tools. Pick what works for your use-case.
In essence this is an old Idea that have been on the cusp of making the professional application developer obsolete since COBOL was invented back in 1959.
There is a cyclic nature to this and at i don't see any real difference in this generation of tools then something like SAP ABAP in that it will not also develop into a new sub-specialization that Leeds to an increase in the need for full time programmers.
While I do primarily backend data work these days, I spent a lot of the early 2000's working for an agency that built websites for people and companies. Many of which would have been simple enough to throw together in Squarespace.
I'd always thought I could fall back into building websites if this didn't work out, but I feel like that's falling out as my backup plan. I still try to keep up on CSS and JS though, just incase.
So I think they are great, because who wants to reinvent the wheel? It's so much nicer to pay someone else to deal with the problem while I focus on building solutions to novel problems.
Is it a paradigm shift? Yes, in the same way that Excel was a paradigm shift. When you make it easier to solve a class of problems, then people solve more problems in that domain.
Excel radically transformed so many industries because it suddenly became dirt cheap to do complex costs analysis, so instead of paying an accounting firm to run two or three various costs analysis for a product, they could instead be paid to find the optimal solution for a product to hit a specific price point. Suddenly, we have candy bars with 54.51g of chocolate in them.
Something to keep in mind, is when the cost to compete in a segment goes down, competition increases to the point where the cost to compete is driven back up. If anyone can build a competing product in a weekend with 0 background, then competing products are going to pop up where ever money is being made. And one of those competitors is going to innovate their way to the top, through technology, marketing, corruption, or some other means.
We built the website on Squarespace ( a tiny bit of custom JS because I wanted a specific UX, but minor). When we are fully launched and selling product, we'll probably continue to use squarespace, but we'll see. It suits us for marketing purposes and capturing interest now.
At the same time, we're working in the hardware space (healthtech building an EEG), so we write all of our firmware, and we've got AI running on google cloud, so all the data pipelines that go along with that.
We're building the front-end for our mobile app, but using Google Firebase for the user account, and other simple user-data stuff that we need. I consider Firebase to be mostly no-code, I code up the front-end, but don't need to do anything on the backend.
The more interesting thing I've heard of recently is Fl{0} (https://fl0.com). They're a Sydney based start-up that is building a low-code style backend system. I'm not completely sure I get it, maybe it's just another version of nodeRed, and other similar tools.
You used to be able to get away with a landing page with just a form to collect email addresses - now you need a hell of a lot more polish to get started.
It doesn't matter how nice the UI is, there's a fundamental level of complexity there that requires study and training that also induces anxiety in an untrained person.
No-code can handle a significant percentage of work. In the system I experienced ten years ago I would guess 20-30%? In that case, we had close collaboration between developers and business people within the same building, and some of the business people were even willing to be trained in SQL (!). It's certainly useful in that regard, but it doesn't eliminate the custom stuff. The eventual interactions between the custom and no-code logics are something that requires balancing too.
There is a fundamental tension between “what computers understand how to do” and “the problems that humans are trying to solve with computers.”
Every programming language lies somewhere between one of these two fixed points. The goal of many if not most programmers is to end up with a system that lets you express all of your domain-specific problems as clearly as possible, abstracting away the fiddly bits that you don’t care about.
There’s a lot of stuff that has to exist in order to get to that level, and we neither agree about it nor know all of what it entails for any specific thing. So Domain Specific Languages (DSLs) are often the best that we can do, and they vary wildly in quality.
Some DSLs lend themselves to being visually programmed. They tend to be rare and niche, and incredibly helpful to the people who can use them. Perhaps more is possible, but it requires a foundation to build upon that does not yet universally or even commonly exist, and may never exist.
But it has limits like everything else. Vendor lock-in is returning similar to the old days of mainframes. But at least this time around the tools are more varied and from different vendors as well as the ability to use one of many languages in most cases.
You can run a bunch of businesses with writing very little code. What they don't seem to include in that no-code advertising blurb is the amount of configuration required for some no-code solutions. Especially integrating each *aaS to the next. That seems trivial but can become quite a project.
The bigger cloud offerings such as AWS create dependencies that might be an issue for a lot of businesses if they try to switch. This includes wanting on-premises solutions for whatever reason instead of the cloud. AWS is more than "hey you can run redis, mysql etc in the cloud". Its constellation of convenience is quite a thing to behold. Gets hard to leave. That's the new variant of the old vendor lock-in strategy: You don't want to leave and it can hurt a lot to do so.
There is also an issue with non-cloud alternatives as inherent to most of the no-code solutions in practical use. Unless of course you have a disaster recovery plan for when your favorite sites go down. We still need to have DR plans even for no-code.
You are ready for the no-code platforms you use to go offline, right?
Haven't mentioned security. Better not forget that either.
No-code means more contract management.
Other types of no-code tools span the entire gamut of IT, sales and marketing workflows. You already mentioned Zapier which for me has been very useful for a niche use case. I was setting up a virtual conference that used one app for selling tickets and accepting payment, and a second Zoom-like app that would host the livestream. I needed a way to automatically send event registrants an email from the livestream app with their conference link. Zapier did this very easily.
Another type of no-code tool that's pretty common is something like Google Tag Manager. Instead of needing developers to set up custom tag snippets in page templates, you can just add one GTM tag, then use a web GUI to add in additional tags. No access required to the production site.
I'm not sure that's as clear as it seems at first. Everywhere I've been involved with them, the flow is like this:
1) Org sold on idea of no/low code tool, "business analyst can build things!" 2) Business analyst tries, fails to build things, calls dev 3) Dev figures it out, could have done similar in a few lines of code. Either a) becomes "expert" in tool or b) goes back to code
I'm not ready to rule them all out, and maybe I just worked with some inept business analysts. These tools are by their nature usually closed source/proprietary, but maybe there's some great ones. But I also wonder if it's not partially fundamental: maybe text is just more concise and expressive than visual paradigms for some problems - there's a reason we still have textbooks for some things.
- spreadsheets :: textbook example
- OS/file systems :: it is hard to imagine times without it, when these operations had to be programmed manually
- relational DBs/SQL :: compared to myriads of ways data manipulation was programmed previously
- shell pipeline :: compared to manipulating processes directly in C. People can be tricked into writing useful shell commands without thinking about themselves as programmers.
There are many [less general] domain-specific examples such as GraphEdit, GUI/web-site builders, yahoo pipes, labview, etc.
Declarative configs for various things (even if they literally called "code" can be also considered no-code solutions e.g., IAAC) or various DSLs that discourage the general code with loops/ifs (even if it is Turing complete formally).
We hire engineers (usually ML, computer visions, etc.) and embed them with clients.
They meet 1-1 with their team members to walk through what they actually do in their daily work.
The eng. can then build light-weight solutions in real-time to optimize & automate those workflows.
It’s like prototyping as a service.
There’s certainly a huge movement around “citizen developers,” but what we’ve seen is these makers get stuck quickly when their solutions need to scale, be used by someone else, or integrate with other workflows.
Computational thinking is the key.
Initially we thought, like everyone else, we’d hire no coders and teach them to think like engineers.
It became obvious quickly that is was more about finding product-minded engineers who enjoy building things that help people and then show them how fast they could do that with these tools.
It’s made us incredibly opinionated about no code tools. Most are too limited for this approach.
What invariably happens is that somebody gets a bee in their ear about some silver-bullet low-code tool, and tries to use it. They maybe get a few simple work-flows to work. Then they try to start doing more complex things, and it falls apart rapidly. Then more requirements are foisted onto the low-code platform, and developers get dragged in to try to build integrations into it and new custom components for it. Usually this is unbelievably awful to do.
Eventually you have developers having to maintain this awful Rube Goldberg machine of crap that they didn't want to be involved in,
The movement i'm most interested in as a backend developer is the no-software movement.
The idea that the entire process of developing and deploying services can take place in the browser. Why install an IDE when i can just code in a browser. Why install git when i can press a button in the browser and have it handled in the cloud. Why run the code locally when i can run it in the cloud and stream the output to the browser. Why install a bunch of software and configure everything to work on my machine, when it can all be handled in the cloud and interfaced via the browser.
I'm a Software Developer, but I don't see why everyone should have to, or feel like they have to, learn to code.
In general, kids and adults alike, but especially kids, should spend more time being active, around others (within reason, these are extraordinary times), and outside - not in front of computer screens.
Not everyone is cut out for or interested in coding, just like not everyone is cut out for or interested in medicine, law, a trade or literally anything else.
That's not a value judgement or a judgement of people's intelligence or lack thereof (unlike a lot of techies, I don't believe we're smarter than anyone else) or a belief that you can't acquire or develop skills - it's just fact.
For example the content team in a company like Doordash won't have access to engineers to help automate content creation.
But people in that team WILL have ideas around how they can automate their processes using a low-code/no-code tool.
Shameless plug - I am myself making one of these tools to help more folks DIY tools, flows & apps without making it themselves. We're here at https://getmason.io
I think in a few years (decades?), "developer" and "programmer" will mean something very different that they do today.
Later, there was the 5th generation movement with Prolog or Prolog-type langauges.
Before that there was Fourth Generation Programming.
Building systems is hard and requires programming. So people look for a way around it, leading to the next generation of "no-code". Then, the systems reach some sort of inflection point where programming is again required to add functionality.
[Edit] See also "No Silver Bullet" for a thoughtful discussion about complexity of problems. This cycle will continue to repeat.
if you want to build something cool now it had better do more than update a database
Not by writing XML by hand without proper tools, but using something built upon this, on an extensible, inter-operated web. Think using modern XMPP for messaging, instead of a zoo of messaging apps that can't talk to each other or Yahoo Pipes on steroids. But that's not the universe we live in and that's not the no-code we're talking about.
Text is just there as a crutch to language-brain. Image brain is fast with concepts, but bad at details.
Your mileage may vary, but my feeling is that no-code will keep growing in relevance, but it's not there yet on what it claims to do.
The people who can program in no-code environments can also program in all other environments.
Sure, there are _LOTS_ of ways to improve the status quo, and any idea should be tried, but I'd much rather explore more interactive programming environments than focus on the input method.
If you can’t code, nocode seems awesome. If you can, it seems like 2D in a 3D world.
Another way to look at it is like computer architecture. We have technologies for holding data and impedance mismatches between them, so we make intermediary caches, integrated/hybrid devices and devices start blending to look like each other 3D XPoint/NVMe. On another scale a Facebook datacentre can look like a macroscale computer architecture. My point is that 'programming' and programmers started out being one thing, but there will be many different forms of this at many levels, in various vertical areas. We already have specialized platform (Shopify) programmers, and self-serve (Zapier/Airtable) and even among those there could be third-party helpers as has happened around Google sheets data collectors/analyzers. Lo-code/no-code is so many things. It comes back to 'any sufficiently capable configuration schema becomes a lisp'. People want to tweak, so they learn to program.
We need the ikea version of software development where a lay person can put together a common type of app and maintenance is mostly automatic. I think the nocode "movement" is here to stay and it's only going to get bigger, in terms of number of apps, and ease of use.
I liken the no-code movement to the introduction of a higher-level programming language. For certain tasks, the higher-level language is more than adequate and a developer (or user) who knows nothing about OSes, file systems or networking, can build an application and probably create value and make money. But the higher-level language doesn't replace the lower-level language overnight, and for certain tasks it'll never replace it.
To use the example you mentioned, if you just want to display a webpage for your co-workers that lets them filter a SQL table, it might take you a few minutes to build that in Retool. If there is a class of such webpages or webapps that could make you money, then it's easy to see Retool as a new higher-level language for building those types of apps.
So, my view is that it's not a paradigm shift for building software, but rather the next step on an evolution towards a more automated process of building software.
Disclosure: I founded a no-code web testing app https://reflect.run
I think the basic reason why low-code / no-code works is down to software bugs and long-tail maintenance.
Bugs are a function of number of engineers, features, moving parts, and significant lines of code.
No-code takes out engineers, moving parts, and SLoC from the equation (as far as the enterprises buying these solutions are concerned), but leaves a lot to be desired in terms of feature set; low-code brings down number of engineers, and SLoC, whilst providing flexibility in terms of bespoke feature sets.
Also, in essence, No-code and Low-code are a natural extension of the cloud computing model in which capex is traded away for opex. And economies of scale, over time ensures Low-code / No-code will be cheaper yet more reliable than anything one (tech-enabled) enterprise can roll on their own. While at some level it is also an indication of 'software is eating the world' phenomena (both in terms of available capital given software economics, and rise in popularity of CS, in general).
The "no-code" where you are building end user apps inside a proprietary, cloud based WYSIWIG editor, that seems like a fad.
The "professions" that get replaced typically aren't professions by the time they can be reliably automated, in that they are usually monotonous tasks that don't contribute to the advancement of any field.
Everything evolves, but the bulk of people creating new software are still coding it after decades, just the same as the bulk of musicians creating new music are still playing instruments after centuries and millennia.
Perhaps our coding tools will eventually become so advanced we can just think it and a piece of software will be created, but that's also boring and unchallenging and will likely have the equivalent creative value of singing into a voice-changing social media filter. We have this in the present day but people still write and perform songs that others perceive as valuable.
The goalposts of what constitutes "creating" reliably move just as much as people continue to need to get their hands dirty in order to craft actual innovation.
The "no-code movement" is perhaps more an example of a "no-movement" trying to masquerade as a movement.
I don't mean to deride it, some things can and should be automated, and this is valuable in itself as it shifts the goals of innovation along. But it's misleading to elevate such things higher than their pay-grade.
And sure, maybe sometime AI and deep-learning could anticipate and create everything we need - "the singularity", etc - but at such a point, that innovation itself has been automated, we'll all probably just happily hang out at the beach, as there'd be no more work left to be done anyway.
Visual Basic was sort of a “no code” solution, at one time (of course, it is, actually, “code,” but the barest minimum possible).
The dream of the C-Suite has always been to toss out those filthy engineers, and generate product directly from the (obviously) superior minds of the executives.
Not sure how well that’s worked out, so far…
At first I was interested in the tool, but seeing how long it’s taken him and his struggles to get things working has convinced me that he probably would have been better served to just learn Python.
"No code" is basically commodification. For some subset of IT tasks, there are now tools you can use to achieve your goals without employing a software engineer. Great - it makes everybody more productive when humans can be replaced by software.
But note that commodity markets, by definition, are low-profit. If you can use some cheap off-the-shelf tool to achieve a goal, so can all your competitors. So people thinking they're going to build the next great billion-dollar web startup off of Wix or Shopify are probably going to be disappointed. They can build a great web startup, but so can everybody else. You can no longer make life-changing sums of money just by being able to throw together a website.
It's more useful to businesses whose competitive advantage is elsewhere. If you make complicated hardware, for example, and just want to be able to sell it without paying the Amazon tax, these tools are great.
Hypercard
Macromedia Director, which later evolved into Flash
VisualBasic, which had fantastic WYSIWYG tools for interfaces
A little later:
Dreamweaver
PageMill
All the early Web tools (there were hundreds)
It is difficult to now remember the cult that existed around Hypercard for awhile, and which lead to spin off products, like SuperCard.
There was a real mania at that time to make it easy for everyone to learn the basics of programming.
At some point after 2000, and especially after 2010, the idea seemed to fade, and the tech industry for awhile got caught up in going in a very different direction: big frameworks, increasingly complex, increasingly abstract, a development system that required more and more tools.
I would like to see some of the old "education for the masses" energy come back.
Devops: Infrastructure as code. or dbt's viewpoint on analytics as code (see https://blog.getdbt.com/building-a-mature-analytics-workflow...)
So I'm seeing it as an exercise in finding sweet spots. There are things that have been mostly manual or point-and-click and people are seeing wins from defining and managing them as code. Usually in terms of reproducibility and testability. Then there are things that people have traditionally done in code (e.g. admin UIs) where maybe most of it can be abstracted away into a point and click tool.
No-code works great until it breaks, and then your ability to debug is going to be very constrained. We're fighting that problem with some no-code ETLs using Stitch at work today, for example.
I work at a fortune 100 company where a team just had to write off over 2 years of development at over $10M. Executives were sold a no-code solution and then instructed their team to use it for some complex business processes (duh). It was obvious to a few of us but wow, what a shame.
First - there's no complete solution. notice how they all have a "custom code" feature for you to fill in what's missing using JS or proprietery language. And you need a developer for that. These platform only work so long as you stick exactly to the use-case they had in mind.
Second - Business/non-dev users don't have the skills nor the inclination to use these platforms. It may look simple, just drag'n'drop, connect the dots, But what if it fails? why did it fail? when will it fail? they don't have the experience and mindset to debug and account for edge cases, and they don't even want to learn how to do it! no matter how easy the no-code platform is.
These conclusions I payed for in blood, sweat and money.
But I think they're really cool none-the-less, as a developer. I can build a modern react web application with the best of them, but I still pay for a squarespace personal site. At work, we use a ton of zapier and retool; when the problem space fits, its just less dev work. But the devs are the ones who do maintain it, at the end of the day.
I don't think it's a movement that will gain popularity more than it is right now, most people who use it for a while will realise its limit and either hire a software dev or jump into coding.
The organizational problem is controlling ad hoc app proliferation by non development units and thereby creating unsupported shadow systems. So, when used by dev teams I see no problem, but usage by operational units should be highly policed.
What I don't like is the trend of teaching people to almost reach their goals, without also teaching them how to fill in the details that the "Do What I Say" tool cannot.
What would be a more laudable and practical goal would be something that eases people into more advanced programming, or points them down different paths that are associated. It is useful to know "No, I don't want to do this, but
So in the end, I think the "No code" movement is just the latest iteration of sky high dreams. It looks like training wheels, but it is anything but.
This would really clear me up for valuable work instead of having to rehash the same quick fixes for broken data modeling paterns.
Personally, my money is on hype. All the demos I've seen are pretty impressive, but very shallow. Large apps are complicated beasts, and scaling usually ruins simplistic demos pretty quickly. Furthermore they seem to suffer from the same issue that prevented COBOL for making programmers obsolete: defining requirements correctly is very, very hard.
Software development has become far too complex without the right sensible abstractions keeping things under control.
Every developer would probably want an Airtable control to drop into their app, that they can use to build up their schema and then add custom functionality. But there isn’t one. I think mostly because there were too many technologies coming along at such a rapid pace that integrating became difficult because everyone is using a different tech stack and changing tech stacks all the time. And there are new libraries to do everything. E.g. No one uses Redux anymore. Graphql came along. Everyone is back on SQL. And what’s next?
The pace of tech needs to settle down and then we can build some solid reusable libraries that do the same thing as no code tools.
In reality there is so much no-code/low-code solutions already there in place. Whole Wordpress ecosystem with plugins - you basically can do webshop in couple clicks, if you are writing webshop from scratch then you are stupid.
Then there are pointy haired bosses who think they can substitute their developers with low code. That is also stupid because their company probably needs developers. Like if they are SaaS provider - they ARE low code for other businesses and replacing developers with some low code will make company to be simply reseller of someone else business.
If you are SaaS vendor - you are low code provider for other businesses and from what I see many managers don't understand it and think they can make money on someone else solution.
What I found is what everyone finds; when the tool does not support something, it gets very hard.
I think of that as follows: the request to make that 'impossible' feature came from somewhere; if you rethink the feature so it's trivial to click together with the tool and then convince the owner of the feature to accept that reality, you often get away with it. Just accepting that you don't need certain complexity for things to function well is often, imho, a perfectly fine solution.
If the client or owner does not accept to work this way, I don't use no/low code at all.
I think a lot of developers are very anti-no-code because they know, as any rational person does, that any no-code solution flexible enough to do everything will look pretty much just like programming. But no-code shouldn't be a 'do everything' solution, it should be a 'do a lot of things more easily' solution. No-code, to me, means tools designed to bridge the gap between non-programmers and programmers and allow individuals to access computing at levels that are comfortable for them while on-ramping them towards more and more programming as their needs increase. This is what personal computing is all about.
They live in a difficult bracket to find offering customers in: medium+ projects have most of their complexity in making the business domain model and understanding it's intricacies, well before you attempt to make a computer understand them; no code tooling only cover the latter. Small- projects live comfortably in Excel sheets, as scary as that sound for the reading cohort, it appears evident that a lot of the no code market is already captured by that, and they're not offering anything to challenge the dominant player in the space.
We make tech more accessible for people who can't code and then we move to the next thing.
I saw a bunch of freelancers fail, because they had the impression they could sell people basic homepages as a job for their whole life...
"Data" Driven Development (DDD), if you need a buzzword/acronym, is where I think about code and data in the same bucket (ie. Lisp). I can check a box to enabled something, type some text in a field to provide the i8n label and database field. Easy. Underneath somewhere, there's obviously still code, more complex code, to make all of this work.
Or, what do I think of the so-called "movement?"
As a single independent developer, I am in a bubble. I can't predict the future. I'd like to see powerful rapid development tools out there, but more and more I see a lot of locked up proprietary walled fortresses disguised as movements.
Also, website generators have always existed since the web is the web.
The main problem with website generators is vendor lock-in. If the vendor goes away so does your website. If the vendor unilaterally changes their price structure, you have no leverage. If the vendor comes with any new arbitrary terms of service, you have no leverage either.
If the vendor decides to block your website due to some false positive from an automated system, you may have no recourse and your entire web presence is gone while the problem is resolved, if it ever gets resolved. Meanwhile you have no way to deploy your stuff anywhere else.
I think the 'no code' is just a marketing term to explain something that everyone here is familiar with: the tradeoffs of building with abstractions.
On the one hand, powerful abstractions to build-a-blog-in-15-mins. On the other, the decrease in flex/extensibility and the maintenance pains that come with using tools in unintended ways.
We'll get to a stage where we can build with VR-think-about-a-component-and-see-it-appear or w/e but we all know there's always inherent complexity that eventually requires going under the hood or just straight up reimplementing.
Video of the tool i built: https://www.youtube.com/watch?v=V6_NJ8zcm8o
All technology has natural adoption phases. The technical problem becomes better understood. The technical solution is improved. The market problem and solution become better understood and improved, and presented in terms that make sense from a user perspective, and solve their problem. It becomes easier to use, More people adopt it.
Typically runs through several different companies' lifetimes; some would argue the changes are so great, it requires different companies, with different foci and competences, at different phases.
It makes it easy for really simple websites/apps to be built, but the reality is that business people have no idea of how complex something can be and after they started using no-code tools they hit a hard wall of having to rebuild everything with a real software developer.
In reality though it would be nice if there's a solid hand-off between no-code and the "properly build and tested" world.
That said, they can be good for prototyping or brochure apps/websites that just serve information and have some forms.
Graphical "low-code" programming has been around for a long time in e.g. the control systems community, where people typically have strong math am physics backgrounds (e.g., knowledge of vehicle dynamics), but little experience with programming or software engineering.
Matlab Simulink and LabVIEW are well-known products that offer a low code approach to these fields. Large and complex projects are done with these tools.
IMO the complexity is shifted from interacting with the hardware to wrestling with the tools, e.g. version control, knowing what happens exactly and cooperation is really hard.
Code, especially these days, can get quite insanely complicated and pretty far from being a concise description of appearance and behavior. Fiddling with frameworks and libraries and language features instead of doing the thing you’re actually trying to do has gotten to be too much and no-code fad is the response.
It should also be an implicit call for “hey lets try to reduce complexity” but that is rarely listened for.
You can make a lot of money on sophisticated custom technology, or you can make a lot of money with very little technology or even white-labeling someone else’s technology.
Every business should focus on the basic value proposition on for their business and product and make decisions that support it.
How do we make money, and where is the best place for our time to be invested to make more money? That’s it, that’s the only question there is.
At the end of the day you are still instructing a machine to operate.
Every task that's complex enough still requires a "coder mentality" to perform.
It's just that many people don't want to bother with the quirks of classic programming languages and the technical baggage that they drag around from birth.
The worst feeling comes when you realize you are spending most of the time fighting with the tools than actually solving the problem you had in the first place.
The definition is tricky when you start from a negative.
There is a companion term 'low code' - because people discovered that 'no code' is too restrictive. But that is even more foggy. If a new library comes out and suddenly your program shrinks to a short script - is that 'low code'?
Seems potentially lucrative if you can build a successful business around one.
None of them ever have, of course. It turns out it’s really difficult to make and maintain general purpose tools that allow for non-engineers to generate the end result they want. If for no other reason this is because of the edge cases. You can get really far, but for the most part I’d describe the limits as capable of a really good proof-of-concept.
Old RAD tools like VisualBasic is far superior than no-code. GUI is better than CLI if done right.
Eventhough we had these tools I still preferred to code from scratch, simply I could not stand the output code, it was messy, full of unused stuff, excesively commented, etc.
I like to look under the hood and understand what's going on. This is not for me.
The problem with no-code is it generally appeals to a class of non-programmers who think programming is hard because of syntax. They don’t understand that coding is hard because it’s about understanding and solving hard problems that touch human computer interaction, legal/compliance and computer science domains (among others).
It's not a "movement" it's a boring marketing campaign about some tools that are nothing new.
Let's call these tools "shit code generators" instead and try market that.
Generally speaking, if you're doing something beyond building a simple form or table, and have some serious business logic to implement, in my experience, code is the only way to go. Anything else feels somewhat sub-optimal.
On the flip side, my wife and I ran a home bakery for a while and I LOVED the website builder we used. Click, click, click - full integration with credit card processing, email handling, etc. No way I'd sit there at night hand building a website.
And the creators of Smartsheets seem to have heard and run with somebody's maxim that "It doesn't matter what users say they want, they want Excel."
It's funny that in all this thread there is no mention of MS Access. One of the best no code tools there is, and you can find millions of application in many industries based on Access.
Even in the event of a perfect “no code” era, i.e. a future where we speak to the computer and tell it what we want it to do, we’d still have programmers. They just would be doing the job very differently. Maybe we wouldn’t even call them programmers at that point. But the job would be there.
Complexity will never go away and you’ll always need someone to manage it. That’s life, that’s reality.
1. Reducing complexity by reducing capability/power is easy. 2. Moving complexity from one form to another is easy.
The biggest issue is that these limitations are not well understood by the end users of these products. Inevitably, they want something that the product didn't account for and have to grapple either with the complexity inherent in doing it or come to terms with not being able to do it.
If you want to do something really really basic its fine. If you want to do something complicated then its a hinderance.
I have personally seen entire departments move from pen and paper to off-the-shelf boxed software to SaaS and now to no-code apps. You can finally customize your software exactly how you like without hiring a team of developers, and that's a great thing.
Now that being said, there are a ton of "apps" that really shouldn't need to be coded if you aren't making a competitive go of things.
Lower than that, it becomes complicated as we don't have an easy way of abstracting front/back end, the business logic is still business logic.
Some things to help designers do higher level stuff, like layout, but still work below that level of abstraction is a bonus, but this is surprisingly very hard.
Personally I’ve spent more time working on domain specific languages than I have trying to eliminate code.
With that in mind, for quick/dirty things they're great. I've thrown together proofs of concept in NodeRed in 45 minutes that would otherwise take hours / days of boilerplate.
There's tons of advanced software tools on computers that do amazing things without code. We don't call it "no-code", we just call it using a computer.
In my B2B saas company we massively increased customer satisfaction by making it easy to integrate with retool and metabase and then letting anyone internal or external extend the product with new views and functionality.
Hard task. But doable.
Just wrote this piece putting down my thoughts on what I call domain driven no-code platforms.
Code is going to be the most efficient way to express and verify that logic.
The thing is, these solutions probably couldn't be delivered by non-engineers, but these people are able to move extremely quick because of the platform.
On the other hand, I'm not surprised to see developers hating on the idea because our industry has spent decades telling everybody these are difficult problems and they need to hire experts to help solve them.
No. IIRC, companies have been hyping stuff like this for literally 40 years: https://en.wikipedia.org/wiki/The_Last_One_(software)
Then again for some applications it works great: website designers, simple chatbots etc.
COBOL was designed to be used by business people.
Whether it is connecting wires, punching cards, typing in an IDE, connecting code blocks, or making flowcharts - it is all programming.
Over time all software areas will have no-code options.
Bad is where there’s only no code and it’s impossible to drill down. Or use outside of a walled garden.
Good is when the end product is portable and can be worked on outside the tool.
I think the problem comes when noncoders hit a wall and can’t go any further.
Some estimate that 70% of all websites run WordPress. But I can tell you my salary was paid by customers who wanted this 'one custom application' that was not available as WordPress plugin.
I'm building and maintaining 'self-service' BI apps every day since about 2011. It's profitable. So, the more, the better.
If programming was instead seen to be a welcoming, warm, and supportive culture, I don't think no-code would have very much persuasive power. The effectiveness of no-code as a brand should cause more people in programming to pause and consider the fact that the value proposition is not having to deal with programmers. People literally sell products on the basis of not having to interact with our community. That should cause us great concern about the health of our community and should trigger introspection.
The thing with no-code is that there is still code. Only now it doesn't live in git but in a magic ether between sites and services, and in the head of that ex-employee who set it up two years ago.
I love the concept -- quickly spin up an MVP, etc -- but when so much of success lies on execution and so many good ideas need time to be perfected before they commercially viable spinning up things very quickly isn't always the best.
But I think that almost every marketing claim from a No-Code company or those dudes selling $500 No-Code courses is false.
The problem isn't code, the problem is the ability to analyse the problem, formulate requirements and design a solution. How you express that is an implementation detail at best. This is also where the problem with the marketing of those tools lies: it pretends that when you don't write code, you also don't have to do those other things.
Ultimately this is just the same balance you get everywhere else. You have operating systems, tools, interfaces, frameworks, languages etc. that all do various things. Depending on what things you need to do and how novel they are you might be able to use and re-use existing systems, and you'll be adding to the same generic pool of applications that already exist. This is where automation-of-automation shines, depending on the level of genericness.
Regarding problem solving, again, not code-related, you can solve problems in a conversation, on paper, using calculations etc. Yet any anti-code product is marketed as being able to avoid those, but that is not how problem solving works.
Now, if we bring this all together a bit I find a question popping up: is this whole thing actually solving problems that exist? It's very easy to see a 'problem' if you're working in a bad workflow. But the 'problem' that is seen then often isn't the actual problem, but just a symptom. So now we are not solving a problem but 'solving' a symptom. This happens whenever someone is set to 'fix' something but doesn't actually know how to find the problem and then find the solution.
Long-winded Example:
Joe and Bob work at different companies. They need to exchange a bunch of rows of information and they do this by exporting a database table from some web app to a CSV file and emailing that.
Joe (Source) uses some Database GUI with an 'export' button, grabs the file, puts it in an email as an attachment and sends it to Bob.
Bob (Destination) receives the email, downloads the attachment, goes to his Database GUI, uses an 'import' button, points it to the file he just downloaded and now his task is complete.
Joe and Bob won't want to constantly drag and drop CSV files, so they come up with a plan to use LowCodeNoCode Creator Studio XP Edition to automatically export the CSV, email it to a predefined email address, process the email, download the CSV, and import the CSV. From their perspective, they solved the problem! Without writing code!
From a problem's perspective: the symptom is now hidden and the problem is made worse because nobody knows how this process works, why it exists, who did what, and how to manually intervene. On top of that, the real problem still isn't solved. Even the argument that "there is no code so anyone can find out how it works" doesn't hold up because while you don't need to learn some syntax you swap that problem out with learning some tool.
The real problem is Master-Slave table replication, and if we analyse it one level deeper: messing about with a database table that is owned by an application. If you want to interact with data that is owned by an application you don't go messing about with the underlying persistence store, you use the application and if needed write an API extension that does the job. Heck, that API probably already exists in any modern application! But then you'd actually have to know how systems work, how to resolve requirements and how to come up with documentation and scoping and the foresight of future endeavours.
The machinery behind web sites outside of the top 100 ought to be standardized by now.
I wonder if programmers of the day thought that compilers would put them out of a job?
I personally would like to be working on more interesting projects.
I was using it in 1990 to build nocode distributed replicated GUI form and view driven applications.
1) Do it manually. 2) Scale with no-code. 3) Optimize and protect with custom software.
I've spent the past 1.5 years or so building a no-code data analytics tool called Mito [1] -- a spreadsheet extension to JupyterLab that lets previously Excel-based workers make the switch to a Python based environment. Unlike other no/low-code data analytics tools we spend a large amount of engineering time making sure that users are never locked into Mito. We do this in 2 ways: Firstly, every time you make an edit to your data in the Mito spreadsheet, we automatically generate the equivalent Python code for you. And secondly, to make it easy to work with that code, Mito is an extension to your JupyterLab environment. By existing in the IDE that you would otherwise be using if you didn't have the low-code environment, its really easy for users to switch back and forth between working in the Mito no-code environment and writing code themselves.
Practically, what we've seen over the past year is that giving users ownership of the code that they create using Mito and existing in JupyterLab has been incredibly important. The most active Mito users are those that use Mito in conjunction with custom Python code that they or their company has written. They do things like incorporate API calls to access their data, use advanced pandas/Python functionality that we don't support, etc.
TLDR: We believe that no/low-code are most powerful when they are augments to the "real deal" code-first workflow instead of a substitution.
TLDR -- No-code / low-code are basically just SaSS - you still need hire and pay software engineers to build it and use it. I do not predict that it will become a threat to employment or compensation, ever. Longer answer below:
Some of you who remember a time when developing software was really, really hard. The tooling and docs have only gotten better, and the barrier to entry is lower than it ever has been before - it is now easier to become or switch careers (me) into development. Has the compensation for developers fallen? No, we have just gotten more productive, but the demand for software has gone up a lot.
No-code / low-code are tools, and tools do not tend to replace people, but people still need to build and use the tools. Did AWS, kubernetes / docker, and Jenkins make IT and sys-admin folks less valuable? No, they just learned the tools and leveled up - now we call that "devops" and they get paid well.
1) Every symbolic or visual representation of a command or control flow structure in a no-code tool is isomorphic to some construct in a programming language, just more cumbersome to author and manage, especially at scale. Therefore, users of no-code tools are programmers; they engage in programming when using the tool to define some process.
2) Programming with text can be done with a variety of tools, from full-fledged IDEs to Notepad. Programming with a graphical representation can be done only with tools that render that representation (usually, proprietary tools from the no-code tool vendor).
3) Text is more amenable to being diffed, transformed, and version-controlled than are visual representations.
4) Visual representations have a low complexity threshold beyond which they simply become unmanageable. It doesn't take long to clutter the screen and make it difficult to find what you are looking for and manipulate it. Some sort of normalizing or beautifying feature for the program control graph, as well as a search feature, may be added, but these are necessarily more complicated than their text-based equivalents.
5) It's much easier to simply type in what you want the computer to do than to engage in prolonged rat wrestling to construct a representation of the procedure to be followed.
6) No-code is circumscribed: If you are writing something the no-code tool author anticipated, you will be fine, If you are writing something the no-code tool author didn't anticipate, good frigging luck.
7) We've been sold this snake oil time and time again. It was CASE tools in the 90s. In the 2000s, we were literally told that programmers would be made obsolete by the emergence of UML to program conversion tools. (I had a professor who said as much, almost in so many words.) It never takes because with the complexity of real-world software, it becomes an ergonomic nightmare.
8) No-code is intended for two main audiences: as didactic tools for children or the barest of beginners, and as production tools for dilettantes who want to program without putting in the effort or assuming the stigma that professional programmers do. In a production environment, the output of these dilettantes will be abandoned by the dilettantes themselves, who aspire to grander things like marketing, management, or finance; and will instead have to be maintained by... professional software developers, who will curse the original authors' names forever -- thus nullifying one of the touted advantages of no-code to organizations: that you get the benefits of custom programming without having to hire programmers.
In short, in order to think of things more snake-oil than no-code, I have to go to the old standbys of medical pseudoscience and multi-level marketing products. I can see no-code used as a crutch by those who are new to programming and afraid to approach it, but they would perhaps be better served by using something that involves code, but tricks them into believing that what they're doing is not programming, thus alleviating their "programming anxiety". Secretaries were successfully trained to write rather elaborate Emacs Lisp on Multics Emacs back in the 1970s -- simply because they were told that in so doing they were simply customizing their editor, not programming it!
tldr; i think it solves yesterday's problem. people today are both more willing and more able to learn basic coding skills. the hard part for both visual environments and high level languages is getting the abstractions right for the building blocks and i think it's an easier problem with the expressiveness of text.
The underlying ontology behind code is, "reduce problems to a normalized form that can be stored in text, which we have gotten good at managing with snapshots and branches in DVCS".
With no-code, you don't have a normalized form to reduce to. Maybe your project is PowerBI modules or Excel-like superspreadsheets or whatever, but the 'stuff' that your project is made out of is not subjectable to the same kind of rigorous management that contemporary codebases tend to adopt.
The two analogies that come to mind are nosql, a movement which rather quickly discovered that RDBMS -- a normalized form for storing and addressing data -- was a pretty good idea, actually, for many use cases.
While NoSQL found important roles to fill, it is by no means as Big a Deal as the breathless tech media made it out to be, back in the aughts when mongodb first dropped.
The other analogy is double-entry bookkeeping. It's been around forever, and while it's not appropriate for every use case, its resilience and ability to represent complex changes in a complex system over time in a normalized way is similar to how a well-maintained codebase is represented by git (and competitors).
Code is a form for representing thoughts about changing systems which change the world in turn. It implies an ontology -- an "ideology", in the popular sense of the term -- and without that scaffolding, projects get floppy.
I'm much more excited about things like Git Copilot. Did you see the demo at Ignite, where that guy was literally just describing in English how he wanted the minecraft bot to behave, and the model wrote the (perfect) Minecraft scripting to make the bot obey?
That, IMO, is the future. Tools that create code that may or may not require tweaking, but can be still be committed to a repo, and is still something whose provenance and behaviour you can reason about, and diff-view when it changes.
Now, making the resulting code provably correct in a quick, automated way is probably the next thing I'd work on if I was in charge of Copilot development. But this will probably require changes to the languages that people use.
"Here is the code that does the thing you verbalized in English, here it is deployed, and also, here are several proofs, including a formal proof, the code does what is intended."
(Another advance I'd like to see are AST-based DVCS, rather than text diffs, but that is a story for another monologue)
[EDIT: I should mention that I happen to work at the specific Big Tech Company that makes Copilot; however, I work nowhere near the team that made it, and my opinions are emphatically my own.]
I think that within a couple of years, no-code will take over >30% of the software development market
Something like https://github.com/oshalygin/gqlgen-pg-todo-example but easier and more tied into everything already.
Effectively instead of hand coding up the stack, there would be this server that you install and you get auth (implying a user model), GQL, and all you have to do is make the database and define a special file that tells the DB what is viewable or restricted and how that connects to the user.
The package would be 100% open source but would have like modules you could enable to connect it to auth0 (or others) or use a pre-created schema.
That's the stuff that should have been turned to low code by now and I still don't see much progress.
I like the tools coming out. UX designers, Airtable, etc. I don't view it as nocode, simply as developer and business tools.
No-code is basically the art of creating solutions (native apps, websites, web apps), which could have been written with code but instead using visual methods (without coding). Most no-code tools use a visual drag-and-drop interface. A lot of them have pre-built templates that you can customize. There is also a slight difference between "low-code" and "no code".
With "low code" a lot of things can be done with a drag-and-drop interface, however, some coding is required to for a finished product. So you ANYWAY need some background in coding. This is typically great for people with intermediate technical skill.
What can be built with no-code?
Mobile apps, web apps, websites, workflow and automations, marketing tools, payment systems, and the list goes on. Basically, "typical" products & MVPs benefit the most from no code. So founder can built something in weeks, really fast. For example, WeLoveNoCode (https://welovenocode.com) connects founders with the best no-code developers to build their software and apps without a single line of code in like 10 days. All that is based on a monthly subscription.
Why all the hype?
Well, ho code has A LOT of the advantages:
- will save you money
- You can build and test your ideas quickly
- Anyone can use it > Designers, product managers, marketing managers now have the ability to make their ideas tangible products.
What are the challenges you may face?
Just like new thing, tools have to be learnt and they all have their learning curves. However, it will take you much less time and resources learning how to use no-code tools. Unlike low-code tools, no-code tools have a limit to how much they can be customised. If you want to change every aspect of your product or want to build very complex products, no-code tools may bring some limitation. However, there’s so much innovation and growth with these tools so I expect these barriers to reduces in a few months.
I should add that there’s no limitation with scalability. No-code tools have the capacity for serve increase to allow as many users as possible without breaking. These tools are also very secured.
