[throwawayacc2]

Precisely! I saw an NDC Cooenhagen talk recently. I think it was called “Biggest mistakes in programming” or something like that. In the talk the guy mentioned at some point fixing a db problem.

The way he described it, he was contracted to describe the problem and provide guidance on how to fix it. Not to actually fix, just analyse and describe the solution. But the problem was so simple he just made the fix and offered to do it there and then. They didn’t accept that, they insisted on getting a report and steps to fix. So he does that. He sends them a document and doesn’t hear from them for a while.

Six months later, he gets an email “Can you please come over to discuss your findings?” The “discuss your findings meeting” he describes as being easily a £100.000 meeting.

All this could have been avoided if they just did the fix there and then. But there is a culture a bureaucracy and ass covering.

I have no doubt, this sort of thing is prevalent in other industries as well. It’s not always reasonable safety regulations. Often times it’s bureaucracy running in circles and driving up costs for no reason .

[svnt]

Probably there was a long history of people proposing fixes to this particular problem. While a specific technical issue was obvious to him, the problem was not understood at that level by those in charge. Those in charge also had far more to lose than he did by accepting the input of yet another expert on faith.

Chalking this up to pointless bureaucracy is in a sense the inverse of the “build it like that but six inches to the left” class of requests from non-technical stakeholders.

[P5fRxh5kUvp2th]

If it's not understood then those are the wrong people to be making decisions wrt to the problem.