[closeparen]

An interesting thing with developers getting involved in those boxes-and-arrows UI things is outages. I made a mistake with one once, and the postmortem quite reasonably asked:

* Where was the design doc?

* Where were the alerts?

* Where was the code review?

* Why didn't you write an integration test?

* What do you mean it just rolled out to production instantly?

When we're considering options in advance of building something, it's a more time-efficient, less wasteful alternative to programming. But having built it, everyone acknowledges that what we have done is programming, and now they wonder why we've programmed so badly.

Maybe the standard IDEs, Git, code review, CI, metrics, and incremental deploy workflows were fine actually?

[Towaway69]

For me, none of the learnings is a direct result of using a low-code, arrow-boxes environment. I can deploy instantly to production using any programming environment, if I don't automatically have design documents when using a much-code environment.

Without discipline, any programming environment can lead to failures.

It is true that there aren't any well-defined workflows for using an arrow-boxes environments but that does not mean that these environments don't support specific workflows.

[closeparen]

Are these environments attractive because boxes and arrows are actually better than characters for expressing programs? Or are they attractive because they encourage you to skip steps that turn out to have been important? Sure, you can replicate a normal, responsible development process with a no-code tool, but at that point do you really have a compelling alternative to a more traditional programming environment?