[DrNosferatu]

Quality engineering has to be *repeatable*.

If it’s not described, and only works via the “minds of a few engineers”, you get amateur treehouse-quality engineering like the 737 MAX.

I guess chance can make it work well like that “once” sporadically, but when you need to touch that code again to maintain it, we go back to the amateur treehouse.

[thimp]

I think that's a vast simplification. It doesn't have to be repeatable at all. Objectively repeatability is about elimination of waste and expenditure. The big one is qualification and testing because that's what filters all the crap out. Actually I've worked as an engineer where we had to throw 20% of the products we built out because they didn't pass qualification.

And of course that is where the cost savings are usually made because it is seen as a null function in some businesses. It creates waste and reduces delivery and ROI. Those are all symptoms of other problems in the business but that's how it is generally perceived. And sometimes clients are happy to receive muck if it's cheap.

But that's also how we get planes that crash and Microsoft firing their entire QA and delivering shit for the last half a decade.

And that in turn is because management and project management culture is data driven by people who have no idea what the fuck they are doing whatsoever.

[EchoChamberMan]

I once had to explain to a manager of hundreds of people why reproducibility in engineering (and science) is important. Not good.

[bruce343434]

What has been, in your experience, a repeatable process for quality engineering? How much does it depend on the kind of software one is engineering, or is it applicable to any kind of software with any kind of constraints?

[EchoChamberMan]

Repeatable processes require long term strategy.

[edit] Too many of these people want tomatos, so they plant a tomato, when really they want seasonal tomatos, and need to consider a farm, and take into account growth cycles. The term I like is "sustainable development."

[bruce343434]

I was hoping for more actionable, or at least concrete, advice...

[EchoChamberMan]

Some complexity is irreducible.

As mentioned by user "phkahler":

> 1) Come to work.

> 2) Look at the current state.

> 3) Decide what the product needs from you.

> 4) Do that.

> 5) Use git.

> Steps 2 and 3 may involve communication. Step 5 is tracking changes. Have a PM that tracks main things people are working on and estimated dates (not dictated dates).

> This is how my current job works and we are unbelievably productive.

[edit]

I like the book "phoenix project," and I think they wrote "Team Topologies" which I am curious to read.

[edit]

In general, psychological safety was the number one factor for productive teams, according to a massive google study. From this viewpoint, it's easy to see why there are so few productive teams, as there is little to no safety for most people. Remember though, "There are no silver bullets."

[Edit]

The goal should be continuous delivery imo.