[Reading time: 1 minutes 36 seconds]
Some friends of mine who are doing research similar to mine have independently come to quite similar results: most teams struggle with testing.
Be that in nascent fields such as serverless, or old, traditional fields like embedded systems.
And I’ve spotted something like that in my DevOps research as well: assuring good software quality it hard.
Why is that?
Well, part of it is: if you make software quality about testing, you’re doing too little too late.
The fight for good quality begins way earlier, and it ends after what might be called the “QA stage” of traditional software organisations.
At the core, this is what DevOps is about, in a major way: working in ways that make it easier to create software of good quality, and make it harder to create software of bad quality.
And, oh by the way: it’s not about software quality anyway.
It’s about product quality.
And software is just a small part of the product. The product also comprises things like UX, or documentation, or processes – or people!
You see, any non-trivial system (i.e., product) will be used by people, operated by people, maintained by people.
People are part of the system.
And this is the miss-the-forest-for-the-trees thing about DevOps: it tries to keep the people who make up part of the product, visible and allow them to take action.
Not just be somebody who gets the product inflicted on them, but having a chance to actively shape the product, and have the necessary autonomy to run it as best they can.
I think that’s a fundamental difference to many things that came before it, that placed the focus on whatever aspect or portion of the product.
DevOps tries to deal constructively with the fact that people are, and will always be, part of the product, the thing that you’re trying to offer your customers.