What I meant was: a given system either A) doesn’t have the flexibility to stand up in the real world, or B) does have that flexibility, and therefore has all of the complications that are part and parcel of programming, but because it tries to pretend not to be programming, it isn’t amenable to the usual programming tools and techniques. Of which we’ve come up with a few good ones over the past fifty or seventy years.
No code is absolutely the direction to push to include more humans in the power of computing. But once you’re paying engineers to optimize your no code (like the airtrble timeout example in this article) you’re better off grabbing an engineered tool for that part most of the time.
No code is absolutely the direction to push to include more humans in the power of computing.
I really hate the term ‘no code’ because it’s misleading. ‘End-user programming languages’ are a much better description of what’s actually happening: you’re still writing code, but in a language that is designed to require understanding of the business logic and not understanding of computer science.
That doesn’t mean that no one needs to understand those principles, it means that you have a strong separation of concerns. The business-logic expert writes[1] something in an end-user programming environment, a software engineer builds the components that are exposed in that environment.
The problem with such attempts is evident when you look at the history of things like COBOL (or maybe even BASIC): in the end, where the rubber meets the road, people will still look to professionals to do the thing for them because it gets complex quite quickly. And the professionals by and large don’t want to touch that shit with a 10-foot pole (for good reasons, most of which are in the article). So you end up with something that you can’t seamlessly “scale”. And the more they try to make these “no-code” things scalable, the more code-like they become.
There just may be a middle ground, but I don’t really buy it - you can’t teach non-programmers to build something in a way that fits development’s best practices such that it can be extended programmatically in a sane way (not without turning them into programmers, that is).
That’s pretty much what I took away from it, too. It was interesting to see both that how far “no code” solution could grow and how utterly typical the migration story was.
I am by no means a no-code advocate, I’m actually pretty skeptical about it, but … seems like things went fine? They started with the no/low code tools, it allowed the business to grow quickly, then they had problems that always come with growth, but they solved those and the business is still going. That seems kinda like the whole point of these tools?
Like, what did you expect, to ride on airtable into Amazon level traffic? Of course these tools would crap themselves under load. Using tools like that is, in a way, technical debt, and not all technical debt is bad. In this case, it was clearly a business enabler, and the business was able to pay for it without drawing in interest.
Or maybe this was way harder and my perception is just being warped by happy marketing speech, I don’t know.
I also get the impression they’re not trying to bash no-code (except in the title), but maybe they had a bit of a rude awakening if they didn’t expect no-code to be unscalable and had to scramble to “replace it with code”.
Cloud Run + Go + having a cache per instance that is populated with data from the DB when they start, is a method I have good experience with, for performance and scalability.
I do not think that ‘no-code’ can replicate design-patterns, or enforce idioms, or leverage SDLC tooling associated with a full-fledged, mature programming language.
The typical experience of building a large application in no-code environment, probably mirrors that of building an application from an opinionated template/boilerplate (only, obviously with a much larger support in tooling).
The typical experience of selling/buying no-code system, also mimics (at a different scale) the arguments for an opinionated template/boilerplate.
I cannot claim that I know the answer to this, but one of the better way to build no-code systems is
through:
a) establish business vertical DSLs on top of a mature programming language
b) build boilerplate/template/UIs for industry specific DSLs defined in ( a )
c) create a fully bi-directional code-to-UI parity across ( a ) and ( b )
d) Enforce selective design patterns through Build and documentation subsystems of the overall tool
e) Ensure full integration of the system with modern SDLC tools (from code reviews, to debugging, to bug and feature tracking)
One of the hardest things, that I could not even describe in the above list – is the transformation from a ‘use-case’ to a ‘modular, layered’ construction.
Most end-users think in terms of ‘use-cases’ when it relates to a system functionality. But programmers then ‘translate’ the use case into a composition of functions and data flows that ‘mixes’ up the ‘implementation’ of the use case using the functions that already exist.
That transformation is difficult to describe, teach, reason about, and even more difficult to formalize using tools like tensors, categories, sheaves, etc.
–
I am not particularly familiar with the exact tools that the FINN uses, but have experience with other tools like that from the past.
With regards to bringing programming to the masses, I think programming and related ecosystems need to advance quite a bit.
We also cheerfully borrow common language terms (eg form, ‘services’, ‘masters’, chain, sink, throttle, etc) – to help us by way of analogies, but that ‘speak’ does not really translate well into common language.
Spreadsheet and SQL, I think, showed us a way to do improve here, but the journey is slow.
There is no such thing as no-code. Only weird-code.
That’s not quite helpful. Weird gets stuff done.
Perhaps there is no such thing as no-code. Only code you can’t actually change.
What I meant was: a given system either A) doesn’t have the flexibility to stand up in the real world, or B) does have that flexibility, and therefore has all of the complications that are part and parcel of programming, but because it tries to pretend not to be programming, it isn’t amenable to the usual programming tools and techniques. Of which we’ve come up with a few good ones over the past fifty or seventy years.
Make is no-code?!
Ohhhhhhh.
No code is absolutely the direction to push to include more humans in the power of computing. But once you’re paying engineers to optimize your no code (like the airtrble timeout example in this article) you’re better off grabbing an engineered tool for that part most of the time.
I really hate the term ‘no code’ because it’s misleading. ‘End-user programming languages’ are a much better description of what’s actually happening: you’re still writing code, but in a language that is designed to require understanding of the business logic and not understanding of computer science.
That doesn’t mean that no one needs to understand those principles, it means that you have a strong separation of concerns. The business-logic expert writes[1] something in an end-user programming environment, a software engineer builds the components that are exposed in that environment.
[1] Or, often, draws or drag-and-drops.
The problem with such attempts is evident when you look at the history of things like COBOL (or maybe even BASIC): in the end, where the rubber meets the road, people will still look to professionals to do the thing for them because it gets complex quite quickly. And the professionals by and large don’t want to touch that shit with a 10-foot pole (for good reasons, most of which are in the article). So you end up with something that you can’t seamlessly “scale”. And the more they try to make these “no-code” things scalable, the more code-like they become.
There just may be a middle ground, but I don’t really buy it - you can’t teach non-programmers to build something in a way that fits development’s best practices such that it can be extended programmatically in a sane way (not without turning them into programmers, that is).
That’s pretty much what I took away from it, too. It was interesting to see both that how far “no code” solution could grow and how utterly typical the migration story was.
It’s nice to see people use ‘no-code’ as it should be used - get to market quickly, move on when it no longer works for your use-case.
I am by no means a no-code advocate, I’m actually pretty skeptical about it, but … seems like things went fine? They started with the no/low code tools, it allowed the business to grow quickly, then they had problems that always come with growth, but they solved those and the business is still going. That seems kinda like the whole point of these tools?
Like, what did you expect, to ride on airtable into Amazon level traffic? Of course these tools would crap themselves under load. Using tools like that is, in a way, technical debt, and not all technical debt is bad. In this case, it was clearly a business enabler, and the business was able to pay for it without drawing in interest.
Or maybe this was way harder and my perception is just being warped by happy marketing speech, I don’t know.
I also get the impression they’re not trying to bash no-code (except in the title), but maybe they had a bit of a rude awakening if they didn’t expect no-code to be unscalable and had to scramble to “replace it with code”.
Cloud Run + Go + having a cache per instance that is populated with data from the DB when they start, is a method I have good experience with, for performance and scalability.
I do not think that ‘no-code’ can replicate design-patterns, or enforce idioms, or leverage SDLC tooling associated with a full-fledged, mature programming language.
The typical experience of building a large application in no-code environment, probably mirrors that of building an application from an opinionated template/boilerplate (only, obviously with a much larger support in tooling).
The typical experience of selling/buying no-code system, also mimics (at a different scale) the arguments for an opinionated template/boilerplate.
I cannot claim that I know the answer to this, but one of the better way to build no-code systems is through:
a) establish business vertical DSLs on top of a mature programming language
b) build boilerplate/template/UIs for industry specific DSLs defined in ( a )
c) create a fully bi-directional code-to-UI parity across ( a ) and ( b )
d) Enforce selective design patterns through Build and documentation subsystems of the overall tool
e) Ensure full integration of the system with modern SDLC tools (from code reviews, to debugging, to bug and feature tracking)
One of the hardest things, that I could not even describe in the above list – is the transformation from a ‘use-case’ to a ‘modular, layered’ construction.
Most end-users think in terms of ‘use-cases’ when it relates to a system functionality. But programmers then ‘translate’ the use case into a composition of functions and data flows that ‘mixes’ up the ‘implementation’ of the use case using the functions that already exist.
That transformation is difficult to describe, teach, reason about, and even more difficult to formalize using tools like tensors, categories, sheaves, etc.
–
I am not particularly familiar with the exact tools that the FINN uses, but have experience with other tools like that from the past.
With regards to bringing programming to the masses, I think programming and related ecosystems need to advance quite a bit.
We also cheerfully borrow common language terms (eg form, ‘services’, ‘masters’, chain, sink, throttle, etc) – to help us by way of analogies, but that ‘speak’ does not really translate well into common language.
Spreadsheet and SQL, I think, showed us a way to do improve here, but the journey is slow.
In response to the title line “No-code isn’t scalable” – No-shit :P It’s not supposed to be.