The intent was not to say that you have at least one rule that breaks the rules. I'm sorry if I wasn't clear. There are many different ways to be abnormal - having an idiosyncratic rule is only one possibility. Some might find an extra rule. Some might apply old rules in new creative ways. And some might throw out one or two rules and replace them with an organic process.

There is no one right balance between structure and creativity. A lot depends on the management talent of the organization and its inherent culture. Culture can change over time, but not by fiat and only rarely by radical breaks. An organization that has spent its entire life running development by a strict waterfall model isn't likely to do well if it goes to a few seminars and suddenly adopts extreme programming (XP) in all of its departments. XP is as much a culture as it is a technique and cultures do not change all that quickly.

An organization with managers that are themselves good programmers and teachers will have different options than an organization where managers have been cultivated to apply rules and follow orders. Both can find ways to excel, but only if they really understand what they are good at and where they need to grow. Even then, they will only excel if they set out a realistic staircase towards their goals. What makes the resulting practices "signature" is that they are closely matched to the organization rather than some external standard of "best".

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. Focusing on process and matching process to people is hard and uncertain work and many people want short cuts and certainty. The best practice discussion of the late 1990's wasn't supposed to be a fancy name for the methods and procedures manuals of the 70's but that is what it seems to be becoming. 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?

Best, beth

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!).