We've all experienced it.
All of our experience would expect a "yes".
All rational thought would predict a "yes".
And yet we receive a "no".
And why?
"It's our procedure"
Now a procedure in itself is a useful thing. It allows us to codify a set of actions. It allows us to standardise for consistent outcomes.
Where it goes wrong is dogged adherence to that procedure in the face of overwhelming logical argument against it.
"Oh, we've always done it this way"
"I'm just following the procedure"
"The procedure doesn't allow us to do that"
You can't help at times to think that when you are on the receiving end of the "no" that the procedure was put in place to frustrate you.
My personal bugbear are procedures put place by the Change Advisory Board (CAB). I'm specifically talking about procedures controlling the release of software changes to production systems.
The procedures normally start as well meaning - they are trying to protect the stability of the production environment.
But over time, they bloat and additional rules are tagged on in reaction to received & actual production problems.
Before you know it, even the smallest change is being signed off by half a dozen department heads and a couple of board members.
In one client, I was asked to be one of those department heads.
I'd done for other organisations in the past and was familiar with the role. So I asked what my responsibility was in the processes? What was I signing off on?
And I was told - "Just that you are aware of it".
Sorry, but how does being aware of it protect the production environment?
This client's process had grown overtime, and due to various production issues, the sign off list had grown and grown - till almost everyone at an executive level had to sign off on any change.
For some, the "sign off" was a rather late in the process (I'll come back to that in a moment). While most where adding no value to the exercise. It was purely a rubberstamping exercise.
For those that may have value in the sign off, almost certainly they should have provided input before we reach the point just before go live.
A board member pulling that change as "its not the right thing to do" is way too late in the process. We've invested time and effort in building, testing and preparing the change. The decision to do the work or not should come before we make that investment - not after.
And this is common with so many of the "protections" that we expect to come from this bloated process. So much of it should be happening elsewhere in the activity.
Often the intent of the procedure is (or was) correct - but there are just better and more appropriate ways to handle it.
So next time someone questions the validity of a procedure; take a moment to reflect on if its still the correct thing to do.
In this week's episode I continue look at Professionalism with Software Development through the lens of the Programmer's Oath by Uncle Bob Martin. In this episode, I take a look at the second Oath:
"The code that I produce will always be my best work. I will not knowingly allow code that is defective either in behavior or structure to accumulate."