Agree. I was going to add cargo-cult, idealistic, and nonsense. I think reading this guy's list actually killed some brain cells.

The problem is not just that we tolerate bullshit: we reward it. I'd bet he gets paid quite handsomely to trot out this bilge.

Here's a thing close to my heart: "Knowledge work has unique concerns, unrelated to those of a factory or construction site." But notice how he doesn't talk about any specifics, or recognise that there are shades of difference in knowledge work: e.g., it's easier to make determinations about delivery when adding well-understood and tightly scoped CRUD pages, than it is when delivering a more R&D oriented outcome. Don't get me started on the Toyota nonsense though because we'll be here all day.

Another bugbear: talking about outcome versus output without being specific about what you mean with these terms. Grr. And the first point about processes: they don't serve people, they serve business outcomes. Sometimes those things coincide; often they don't.

I was going to pick a few to complain about, but there are just so many things on that list that are wrong or contradictory.

Simple is a very relative thing, qnd not everything can be "simple". Not everything is a transient thing, especially if you're trying to improve ypur customers lives. Tinkering qith parts is often the only way to improve a system and setting your sights on changing everything at once is setting yourself up for being overwhelmed.

It's just one overly-dogmatic, "new age bs" after another with little though to what the consequences of these heuristics would be.

> quality is not negotiable? Really?

I read this as "certain principles must be upheld at any cost" and I agree with that. 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. Or to phrase it the other way around: If your project cannot reach that basic quality level, maybe it should be ended right away, because it clearly lacks funding/resources. As a freelancer I wouldn't take that job.

> Negotiation is not collaboration? Really?

Well it can be, but it also can't be. The phrasing on this one is a bit vague. But if you read it as "just defending your interest and not trying to discuss common goals and the goals of the other side is not collaboration" it would be true again.

The great thing about vague bullshit is that if you squint really hard, there's always a semi-plausible interpretation which makes sense. See also: fortune cookies, horoscopes.

You are right. But I read this as someones collection of ideas anways not as universal priciples that must be applied everywhere. I tend to favourably read into other peoples statements if in doubt (especially on HN)

> I tend to favourably read into other peoples statements if in doubt (especially on HN)

That's a commendable character trait, but if you have to twist a "heuristic" beyond recognizability for it to make any sense, then what's the purpose of that heuristic?

Hard agree. A heuristic can only be said to work if it means the same thing to everyone. Like, if the list means anything to everyone, then how can we say that the list is responsible for success or failure?

Otherwise what are we saying the causality is? Like, that the list is just somehow inspiring everyone to be successful? So, like, if we just believe enough in the list we'll get it done? No thanks. I'm not going to pray to some poetry.

I appreciate that you are looking at this with a charitable eye. There's a lot to be said for that. And yet, when someone words their heuristics in such absolute and categorical fashion, they stop sounding like heuristics and start sounding like moral ultimatums; which are anti-heuristic.

I, too, make lists of heuristics. And one way I test them is to ask "how could this be completely wrong? Is this really what I mean?" The common idea of negotiation is the process of coming to an agreement by each side being willing to give up something they want (at least in principle) in order to achieve something else they do want. It seems to me that collaboration involves a great deal of negotiation. So, is the OP talking about BAD negotiation? Then say so.

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.

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"

I mean you can have worse quality if you want. But won't have the effect you want. Aka speed. In fact the opposite is most likely to happen.

You can really feel the thought leadership on this one, can’t you?