If you want to trust your product, you need to trust your development process

[Reading time: 1 minute 45 seconds]

Eh, why care about trust?

Trust is just an emotion, but we’re in the very un-emotional, objective business of building software – aren’t we?

Whatever the development process, you’ll shake out the bugs during testing. Easy.

Be honest: that has never worked.

“After development” is way too late in the game to make meaningful changes. At that point, you’re completely committed.

To me, doing things this way always reeked of an organisation that didn’t trust itself. Everything goes according to plan (yeah right) until the very end, and then you just shake the bugs out and ship.

Digitalisation must be the biggest misnomer of all times

[Reading time: 52 seconds]

Digitalisation feels like such a misnomer.

Because it seems that it’s about technology.

But really, it’s about people.

Imean, sure, technology is in there somewhere. But technology is meant to serve people, not the other way round. If people aren’t harnessing technology, it just kinda sits there.

So moving an organisation towards digital technologies isn’t about installing software somewhere. It’s about people working together.

This, of course, is also what DevOps is about.

The relationship between organisation, architecture, and product quality

[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.

Service-centric metrics are the root of all evil

[Reading time: 1 minute 15 seconds]

I think I may get “Nines don’t matter if users aren’t happy” tattooed on my forehead. I just need to run it by my wife first.

OK, maybe I was being a bit overzealous.

But, really, great metrics aren’t the point. Users getting stuff done is.

And I feel like we all sometimes need a reminder for that.

After all, many of us have probably been on the receiving end of unhelpful reaction by companies to product failures. I claim that this is because common availability metrics are service-centric, not user-centric – and thus misleading and perhaps unhelpful.

The DevOps toilet paper shortage

[Reading time: 1 minute 30 seconds]

In case you’re not yet utterly sick of it, here’s yet another post on panic-buying (or, to use the German term, “hamstering”) of toilet paper.

You might be asking yourself what TP has to do with DevOps, and I couldn’t fault you.

But I feel compelled to ponder the psychology behind this global (by the looks of it) toilet paper frenzy.

What gives?

I have a suspicion that a certain psychological desire for safety is at work.

Null automation mailbag

[Reading time: 52 seconds]

I was surprised to see that so many of my subscribers responded to yesterday’s email about null automation.

I think this warrants a second look.

It seems that what people liked about this tip was how it married several aspect in a very usable, approachable way:

• it’s about technology and its concrete application
• at the same time it takes into account the human/process aspect of uncertainty
• it allows for flexible, efficient reaction to the situation
• it enables communication (because now the process is written down)

But what stuck out most was that this was an efficient and pragmatic way to address uncertainty.