tremoloqui

Projects like this are good for everyone even those who don't want to get their hands dirty. That's because these projects will influence and contribute to other projects that you likely care more about.

This is the same logic behind OpenBSD. You don't need to run OpenBSD to benefit from the security posture and fixes that they provide. Consider your life without ssh.

Probably a good reason to consider contributing to these projects.

A data mesh approach probably wouldn't work in the sort of organization you describe.

IMO - To make it work you need a consistent taxonomy or way of translating from a particular domain to some sort of interchange format.

If you have that then a set of centralized tools can pull from the separate domains using a core set of protocols to produce reports etc.

Sadly, the cats out of the bag and Apple, Google and the rest of us will no longer have the plausible deniability that kept this sort of thing in check.

Soon enough every tinpot dictator in the world will be demanding their particular flavour of device scanning inside and outside of their jurisdiction.

How about re-framing the problem?

Considering:

Reclamation and recycling technology will improve over time. Similarly the economics of processing recycled material are likely to make it more valuable.

and:

Supposing we can protect the surroundings, water table etc.

further:

Supposing, as other comments have pointed out, the availability of land is not really an issue.

Then:

Is it crazy to think that there is value to be found in safely storing this material until it is more feasible / valuable to process?

At least it seems like a better plan than incinerating it.

This seems to be missing or at least conflating the meaning of idempotence.

The draft correctly identifies idempotence as a "property of certain operations", but what the draft seems to describe is locking and caching.

Locking and caching are important to building idempotent operations, but shouldn't be conflated with idempotence which is a conceptual property of the operation.

I like what the draft describes, but it would be better done in the correct context.

The place for opinion in your product is in its configuration. Applications need to be flexible, otherwise they are useless to anyone who doesn't share your opinion.

Opinions are like estimates. The only things we can be sure of is that they are not exactly right and will likely drift over time.

Similar to a shortcut, opinions can be useful - but should not be a limiting factor.

++ for suspending judgement when one doesn't properly understand the arguments on both sides.

We could use some more of that.

To these orgs it's a matter of trust and power.

The solution imo is to remove those parts of the industry that are driving the mistaken consensus.

Build software in small firms or consultancies who will treat it as a craft.

Maybe more a hope than a solution.

Most good ideas predate their branding.

The terms "agile" and "Agile" have two separate meanings.

Big 'A' - "Agile" is waterfall re-branded - an excuse for corporate empire building and business as usual. It involves lot's of meetings and not trusting those who build software to do the right thing.

Small 'a' - "agile" is the implementation of the manifesto, which basically comes down to smart people figuring out how to work together towards a goal, often by taking small steps.

Until the terminology is sorted out the discussion can't help but be confused.