That being said, you might be right about the meta rules. It seems to be a fundamental problem of any discourse on how to improve things.

Its the kind of paradox that makes my head spin.

My read on Damian is also that he values the reasons behind the rules more than the rules themselves, but that isn't how many managers have treated his book. Perhaps you have some ideas about how to break this cycle?

My conclusion that the only way to improve overall quality is by empowering people to make their own informed choices, but then again - I think that approach only applies to the particular segment I belong to (professional services in software development and refactoring). I wouldn't claim that I have found any general solution.

That said, I have to mention that my experience with very authoritarian management is very limited. First off, my productivity takes a hit so serious that I can't defend the solutions I deliver (so I leave). Second, I live in a country where the work culture is very anti-authoritarian (Denmark).

The experience I have is from organizations on the brink of total chaos, where such basic things as having one common sccs is a very rare sight. Such places don't have any standardized procedures for any part of the development cycle and there is nothing apart from the individual developers own conscience and skills that keeps the code free of dirty hacks.

Seen from that perspective, rules are good. Especially if you get fired if you break them repeatedly. I'm talking about rules like "Check code into sccs", "Don't write scripts with over 30 global variables" and "Don't write your own XML parser" (and yes - I can come up with examples of developers who has broken this rule repeatedly!).