Sometimes I get a week full of people telling me what they see, and it is very often a pleasure. That has been this week, more or less.

My old – very old! – corporate objective reared its head again. Working on a single codebase that’s closely coupled to policy has been a fascinating journey, as I’ve watched it become more and more out of date. It was, once upon a time, policy as code. The policy is different now and, knowing how slowly policy changes compared to the real world, means the code was probably out of step before the policy was changed. We might have noticed that the policy, and hence the code, needed to change when people started trying to use the system in a way it’s not designed.

I’m thinking about this a lot at the moment, actually. There’s something about writing a lot of policy and then letting it out into the world that tells me a lot about the way the world is changing, and that’s even within the microcosm of the little corner of the world I inhabit. Is it better to write a policy that describes ‘as-is’, try to change behaviour, and then inscribe that? A kind of ratchet that means we can’t go backwards (although we can, of course), and where the iterations track the maturity of the organisation?

Another mode of thinking says that policy is a behavioural change lever. We write things down and then we use that to try to push people upwards towards the bar. Then we inch the policy up again.

Both of these are kind of bad. I think both of them are bad because the POSIWID. If the system you’re trying to police – the verbal form of policy, I reckon, is police – is doing things that aren’t in the policy you’re facing the possibility of having to change the behaviour of many, many people who aren’t incentivised to change. That means the beatings have to continue until the behaviour changes, and that’s not good for anyone. That means the first approach will result in a policy that never goes anywhere, because the organisation isn’t going to change – but it also means the second approach is doomed at once because the organisation isn’t going to change!

There are lovely, easy bits of policy – sometimes. A policy that I can implement as code becomes part of the invisible nudge of the system. If it’s easier to go along with sensible security defaults, and it’s as quick as not securing things, then folks will never complain and will generally thank you. But sometimes I need folks to change the way they do something that will slow them down, and I have to sell them that this is somehow a good thing.

And if the POSIWID, and what the system does is ‘get shit done’, it’s all kinds of hard to convince them not to do that.