[Reading time: 1 minute 24 seconds]
Yesterday I talked to you about doing things right.
Today, I want to talk about being wrong.
But not just any old wrong, but the right kind of wrong.
Engineering is full of surprises: technical, or human, or business. And surprises in engineering have this annoying tendency to be the bad kind.
So inevitably things won’t go the way you want them to. Or perhaps you learn of a better way to do something.
Read more
[Reading time: 1 minute 44 seconds]
I’ll let the cat out of the bag right away: the hard thing about building great things is that you need to get everything right. All the time.
Many organisations can pull off something great every now and then. But that’s not enough. In order to actually build something great, you need to pull it off consistently.
And that means getting a long list of things right. Hard things.
Read more
[Reading time: 1 minutes 29 seconds]
I saw that on someone’s T-shirt recently, and it really struck a chord with me.
This is one of those easily-overlooked truths. Sounds reasonable to everyone, but judging by actions, it isn’t taken to heart often enough.
Why do you think that is?
I have a theory: numbers are easy, people are hard.
It’s enticingly simple to measure availability, and have a clear, objective, solid figure.
Read more
[Reading time: 1 minutes 21 seconds]
QA is the bane of an engineer’s existence. The pesky people with the clipboards and the checklists, considered nerdy even among nerds.
Terrible, terrible, I tell you.
Yet we all claim that quality is important to us, so we suffer the annoying checklists and clipbards.
Right?
Wrong!
Quality isn’t about checklists at all, just like painting art isn’t about washing brushes. Even though washing brushes may be part of what a painter has to do.
Read more
[Reading time: 1 minutes 45 seconds]
If you’re working in an agile team, chances are you’re calculating your velocity somehow.
Now, velocity is the amount of story points you get done in a sprint (we’ll blithely ignore all the handwaviness inherent in that sentence).
That’s… a metric. Right? It totally is: it’s a number, even grounded in actual SI units. Even better, the number is extremely usable as a tool to compare teams: team A gets 70/sprint, team B gets 30/sprint. Clearly team A is better than team B.
Read more
[Reading time: 52 seconds]
Yesterday I wrote about Goodhart’s law: all metrics will be gamed.
And I told you about ways to manage this on a human level. But that only gets you so far.
But here’s another, even neater trick: never use a metric in isolation!
Always find pairs, or even entire networks, of metrics that balance each other.
Maybe you care about deployment frequency. But naively, deploying half-baked unfinished stuff would do wonders for your deployment frequency metric. It would just mean that your product becomes unstable, angering users and obviously serving no one.
Read more