[Reading time: 1 minute 27 seconds]
This is going to be a messy topic.
You see, architecture is a difficult subject anyway. Arguably, one shouldn’t even think to write about it, because you can’t possibly get it right.
And quality is one step further removed still.
So, how do you achieve good product quality? Turns out it’s an emergent quality.
All the non-functional properties of your product: speed, maintainability, stability, reliability, etc. are emergent qualities of your architecture.
And quality is an emergent property of all those non-functional properties.
If your product is fast, maintainable and stable, yet unreliable, it will still be viewed as low quality.
…and maybe now you’re catching on why we’re talking about this in the context of this DevOps newsletter.
Architecture is linked to your organisation by Conway’s law; so the way your teams are structured, the way they work together will unavoidably have an influence on how good of a product you’re going to create.
Shocking, isn’t it? As you debug an instability in your product, maybe you’ll come to the realisation that the bug is not in the software at all (sure, it manifests there, but…) – it may be in the way your teams are structured, or the way information flows.
This is why DevOps is such a human-focused topic: once you’ve worked in this area for a while, you realise that building software isn’t all that much about technology at all: it’s really much more about humans.
And thus, by extension, quality is something that emerges out of the interactions between you, your coworkers, your customers.