Heuristics for Effective Software Development: A continuously evolving list

I just don’t get, after decades and decades, how our industry continues to tolerate bullshit.

Quality is not negotiable? Really? Negotiation is not collaboration? Really? This is not just wrong, it’s almost gaslighting.

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.

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.

Great idea until it isn't. The article is full of bullshit but one thing is very true. We can't predict the future, especially so when we deal with humans and society where stuff changes fast. Strict schemas are more pain than gain here.

> * Use formal verification if possible

Wonder when F* and the like get mainstream so that "if possible" becomes "almost always".

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.