[TeMPOraL]

That's the problem with this list: you can read it any way you like, derive whichever conclusions you want. But then you're only looking into a mirror. On its own, the list is just a lot of feel-good bullshit, mixed with stuff that's just wrong. It has very low information content.

> I read this as "certain principles must be upheld at any cost" and I agree with that.

But that's you reading things that aren't in the text. And by itself, it's not a good principle either:

- "certain principles" - which principles exactly? Of them, which ones are related to quality?

- "must be upheld at any cost" - any cost? There's few things in life that truly "must be upheld at any cost", and they're in the scope of morality, not software. Even "thou shalt not kill" is full of practical caveats.

Everything in software engineering is negotiable, all principles have a price. The important parts are all in the details: what exact principles we have, how they trade off against each other, what benefits do they bring, how much do they cost, how much is too much. This list doesn't touch any of it.

You continue:

> E.g. if your project is dealing with people's health data, not securing that database is a cut on quality you just shouldn't make.

Yes, now we're starting to see a glimpse of something useful - but it's still a bit too vague to work with. Consider:

- What is "health data" under consideration? For example, someone's smartwatch BPM and GPS log, a result of MRI scan, a list of visits at a clinic, and how old they are - these are all "health data", but fall into different qualitative categories, and merit different level of care in handling.

- What is "dealing with"? Storing? Forwarding? Processing? How? Giving access? To whom? Etc.

- What is "securing that database"? Are we talking access controls against the dev team? The company stakeholders? Securing against script kiddies? Securing against Mossad? In which particular way?

You may feel I'm splitting hairs here, but this is reality: quality is always negotiable, and day-to-day negotiations will happen at this level of granularity. Nobody has infinite budget to respond "yes" to any idea that could be presented as "increasing quality" or "increasing security of medical data".

Developing lists of principles and heuristics is of great value - but this list isn't that. The heuristics you want need to account for the reality we live in (including working around organizational dysfunctions and individual cognitive failures). And they need to be formulated in practical terms, or they'll forever be words on paper. Their only job is to help you answer the question, "is it worth it?", every time you consider two options of different quality.

[atoav]

What I argued here is not that you cannot and will not negotiate quality. I argued that taking it below a certain quality level is not an option for most people. You wouldn't for example not escape the commas present within the fields of an incoming csv file simply based on the fact that this would be bad engineering and allow injections or make your program crash. And I am not sure any customer could negotiate me into doing that, it would just be silly.

I was working in VFX where you always had to talk about quality, yet I didn't take certain jobs, because below a certain quality level VFX make no sense anymore (unless bad FX are the point of the movie) — below a certain level you won't be happy, the customer won't be happy, it won't be work that you can show etc.

Granted: coming to this from "quality is not negotiable" is a far stretch, but that was the way I initially read it. Maybe a better heuristic would be "Below a certain quality level, don't bother"