[DDD] Your product is too small

If I may take a wild guess: your product is too small.

Especially if you’re not working at a tech company, like a SaaS or the like.

Let’s say you’re working at a manufacturing company. Building, uh, thermometers. Wouldn’t you say your product is thermometers?

Wouldn’t you agree there’s no software involved anywhere, your product is entirely without software?

Here’s the thing: you might be wrong.

Maybe what your customers are buying is much more than just a thermometer though:

[DDD] Lipstick on a DevOps

I’ve been pondering how language is such an important part of making DevOps succeed.

Or of making it fail.

That’s because with carefully chosen language, leaders can make new approaches really palpable to their team. They can make it easy to understand, desirable to follow, take away perceived risks.

Or they can do essentially the opposite: put lipstick on the pig, use fancy new words and continue with their usual dysfunction and avoid accountability.

[DDD] Functional smells

Software Developer wisdom has it that problems with testing point to problems with your architecture. If tests are hard to write, brittle, kludgy, brain-bending to create: that is what software people call a “smell”: an indication that something might not be quite right.

In this case, it’s the architecture. Testing troubles often point to weaknesses in the architecture which make it hard to come up with good tests.

However, if you consider architecture closely: it has two dimensions!

[DDD] Test plans in DevOps

Traditionally, testing followed a test plan. A mighty document listing what would be tested, and by whom, and how.

Recently I got asked: what might a DevOps test plan look like?

An interesting question really, since the testing landscape has changed considerably. How would a test plan fit in there?

Would there even still be a test plan?

Well, yes and no.

There wouldn’t be a proper Very Important Document headlined “Software Test Plan”, as was the case when I had my first job as a tester, fresh out of university.

[DDD] Explicit and implicit contracts

Recently I recorded a very interesting podcast episode with my old friend Adrian Ratnapala, who works as a site reliability engineer at Google. (Sadly the episode isn’t published yet, but I’ll tell you once it is)

Among other things we discussed service level objectives: what performance you’re promising your customers (internal or external).

And we touched on something that’s actually quite pervasive, yet still rarely actively dealt with: the existence of both implicit and explicit contracts in parallel.

[DDD] Don't make success a negative

“Your reward is: no punishment.”

Have you ever been in that situation? That the best you could hope for was not to be scolded? What a disheartening feeling.

Yet many organisations operate like that. And they may not even be aware.

How many metrics you record are negative metrics? The number of bugs found. The duration of service outages. Important metrics, no doubt, but certainly ones that focus on negative things occurring.