Link to Post

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: Read More →

Link to Post

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. Read More →

Link to Post

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! Read More →

Link to Post

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. Read More →

Link to Post

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. Read More →

Link to Post

“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. Read More →

Link to Post

A while ago I witnessed an interesting conversation about alternatives to the term technical debt. I think it’s interesting to explore those alternative metaphors a little bit: they may shed some light on what technical debt actually is, how to think about it. This is particularly important since it can be so frustrating to get non-technical people to understand it, and that it must in fact be addressed. And it doesn’t hurt for us to explore the concept as well. Read More →

Link to Post

Technical Debt is a well-known concept in software development. It reflects the implied cost of additional work which is caused by cutting corners, sacrificing quality for speed. Some also add other aspects to this definition, such as the accumulation of weaknesses in a codebase as it grows and matures: architecture decisions that don’t quite fit anymore, haphazard workarounds (and then workarounds to workarounds, etc). I’m frequently surprised that even experienced software engineers are unfamiliar with the term. Read More →

Let's Get In Touch!


Do you have a question? A project proposal? Something special in mind? Contact me, and let’s talk about how I can make your team, your products, and your life better