What has ‘no code’ ever done for us?

Generic advice, such as this gem from Jason Yip on Twitter, sometimes triggers an aha moment because of how it looks through the lens of your current obsession:

An effective technique to clandestinely undermine large-scale change is to punish every attempt at incremental improvement because it’s not enough.

The idea is to alienate any potential ally and hopefully convert them into an enemy.

I read this while thinking about no-code automation as an example of large-scale change, and unsurprisingly reflected on how it might apply there. Unsuprisingly, I couldn’t help recognising the technique.

No-code derision

Since I recently mentioned it as an example of no-code derision, it seems appropriate to re-read Alex Hudson’s article The ‘No Code’ Delusion from the perspective of the above technique.

Hudson calls no-code tools ‘wrong at heart’, and lists several problems.

1. Simplified (visual) programming syntax doesn’t lead to simpler abstractions.
2. Simplified tools end up ‘no longer expressive enough to use in many scenarios’.
3. Using a variety of different systems together makes the whole harder to understand.
4. Limited functionality leads to ‘elaborate’ workarounds.
5. Visual models’ logical equivalence to code makes them no better.
6. No-code tools don’t offer testing environments.

While I agree with the individual points, I disagree with Hudson’s conclusion because of a difference in perspective. Points 1-4 refer to limitations that assume that you have access to traditional coding as an alternative approach. However, even in business organisations, most people do not consider themselves programmers and do not have enough budget to hire them for automation projects. When you have no alternative, you might not care if no-code tools give you the same abstractions, only work for certain problems, and result in a complex mess that you then struggle to understand and maintain.

Point 5 - ‘equivalence to code’ - ignores how much more accessible business users find no-code tools, and their communities, than traditional programming. Small improvements in usability have a big impact on large communities who don’t find text-based programming welcoming. Similarly, while point 6 - lack of testing environments - does limit what you can do, you can’t help but notice that this hasn’t stopped Microsoft Excel becoming more popular than text-based programming languages (probably all of them combined).

Each point (unintentionally), attacks incremental improvements just as Yip’s technique highlights. Hudson’s arguments ignore what no-code tools have already done for non-programmers.

What have the Romans ever done for us?

In The Life of Brian, members of the People‘s Front of Judea address the question of ‘What have the Romans ever done for us?’

If you haven’t already seen this, you should. Either way, watch it again, because you can probably use 80 seconds of joy in your life right now. And instead of dismissing change because it doesn’t always work for everyone and everywhere, pause to consider that you just ignored, derided or fought actual large-scale change.