The way I read it, he is starting from the "cogs" premise (which may appeal to some people in some situations), and ends up defending rather humane sounding "local" principles.

One possible tl;dr is:

Objective analysis and queuing theory leads to _rejecting of_ all kinds of Talylorian cogs-and-factory-lines style organizational models and hypotheses in software work.

Here is btw. a book with empirical results about software work perhaps pointing a bit in the same direction: https://www.amazon.com/Accelerate-Software-Performing-Techno...

The studies referred in this book

https://www.amazon.com/Accelerate-Software-Performing-Techno...

Nicole Forsgren PhD and 2 more Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations

You can skip the tar pit of the Scrum Industrial complex (e.g. "here! you MUST take our certificate program!") and the drag setting pointless sprint boundaries and focus on just repeatedly, successfully, ship high quality software. The Accelerate book is a very good starting point - https://www.amazon.com/Accelerate-Software-Performing-Techno...

You mean this book, right?

https://www.amazon.com/Accelerate-Software-Performing-Techno...

Yes, I read it. Yes our org put it in use.

Actually for today's year (2022) the book is not so much of a great news compared to when it was released (2018). Today almost everyone already understood that software development is done this way (at least the right software development process).

In 2018 for me this was an excellent book, it changed the way our organization positioned ourselves regarding software development, and we are very grateful we did that. At that time, before 2018, the "modern" software development companies were talking about "digital transformation", we were already in the agile world for some years but the book gave us a name to go for, "accelerate".

It's an excellent book and I agree with almost everything that is written in it (I work in the software development business for over 26 years).

Hope I helped with this comment.

And I have absolutely read that evil lizard people invented COVID to inject us with microchips. Doesn't make it true.

What I mean with this, is that there'll be many opinions and feelings posed as a fact. About testing too.

Which is why I dislike the OP's article, as I pointed out elsewkere in the comments: the things he poses as "rules" (earlier on he calls them tips, which is better imo) aren't rules: they are highly controversial opinions. As would the statement you read be.

Daily TDD, is more of an "art" than a science. It requires experience, and fingerspitzengefühl.

Though, the science on TDD and BDD is strong and convincing, summarized in "Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations"[1]: TDD and BDD significantly helps to build better software.

[1] https://www.amazon.com/Accelerate-Software-Performing-Techno...

> we need to figure out another way of working that isn’t agile,

Isn't devops the next generation? (I mean devops as promulgated by Accelerate: https://www.amazon.com/Accelerate-Software-Performing-Techno... , not 'smoosh the devs and ops teams together, add Jenkins and hope for the best'.)

And you'd be wrong.

First, I am not aware of any operating systems that are developed using agile methods, and second the empirical evidence is in that agile improves quality, so it would be better if they were.

https://www.amazon.com/Accelerate-Software-Performing-Techno...

Yes, we're in agreement. A coworker of mine pointed me to the book Accelerate [1], which I admittedly still haven't read, which also mentions that organizations where management tries to make sure engineers are at 100% utilization end up being dysfunctional, partly for the reasons you pointed out.

[1] https://www.amazon.com/Accelerate-Software-Performing-Techno...

I prefer studies over anecdotes and found this: https://www.amazon.com/Accelerate-Software-Performing-Techno...

According to this study, you can measure a team's progress and ability with:

* number of production deployments per day (want higher numbers)

* average time to convert a request into a deployed solution (want lower numbers)

* average time to restore broken service (want lower numbers)

* average number of bugfixes per deployment (want lower numbers)

I am curious about other studies in this area and if there is overlapping or conflicting information.

So...shouldn't the focus be fixing the fact that release cycles take several weeks?

This is well researched and discussed in Nicole Forsgren's book: Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations

https://www.amazon.com/Accelerate-Software-Performing-Techno...

If we can all agree that "shipping" is a feature[1] and that "shipping faster" is a competitive advantage, then "shipping fast" is probably one of the first features we should invest in as a team, from leadership to private chef.

If it takes 10 people and six hours to accomplish the release of even the smallest of features, then it sounds like there's a bug with your "ship fast" feature and the team should invest some or all of its resources in fixing that. You probably can't do it over night, but you gotta chip away at it over time at the very least.

If you are looking for justification backed up by real world numbers, I highly recommend the book "Accelerate" by Nicole Forsgren, et.al.[2]

[1] https://a16z.com/2014/04/16/shipping-is-a-feature-some-guidi...

[2] https://www.amazon.com/Accelerate-Software-Performing-Techno...