Computers are wonderful devices to me. A big part of this is because they are internally consistent. Real life isn't like that. Paradoxes abound in real life, but in the world of the computer everything has a reason. And these reasons are internally consistent -- not always knowable, but consistent. We can bank on it. Everytime I debug a really difficult problem, it tests my faith that this is indeed the case, but never has it let me down.

Not so, with people, our requirements, and our designs. Anyone who has sat through an interminable coding standards "discussion" has seen this in action. Everyone has a system, and that system is comprised of "rules" that aim at internal consistency. Suggestions for change or compromise are met with "but that's wrong, then it makes this over here not work right." Which in turn prompts the suggester to point out how if only x, y and z were changed, such inconsistencies would evaporate. And so on.

This happens in design too. "If you introduce a factory method there, it will eliminate that problem." is met by "but then that makes this constructor call problematic, we should choose one or the other." And so on.

TDD and Pairing has been a wonderful tonic for me on this topic -- helping me to delay gratification in my quest for consistency while getting work done -- but recently, I have started to question the high value placed on consistency at all.

Why is consistency so important? Often we take it as a given that consistency will reduce confusion, but anyone who has used or worked on a framework knows that being a slave to consistency (especially when ignoring its cousin "complexity") can lead to complete obfuscation or worse an unusable mess, harder to use than the base functionality the framework was meant to provide access to.

So where am I going with this? Nowhere. Certainly I am not claiming that we should ignore consistency. But I have become mindful that unquestioned obsession with consistency contributes to religious wars, and analysis paralysis, and is otherwise not as necessary as some of us assume. Consistency ain't all that a bag of chips. And henceforth I will question its introduction as a premise.

By the way, I chose religious wars, and analysis paralysis as examples for a reason -- before seeing this darker side of consistency, I would have said that fear of the unknown was a driving factor in those two time-honered geek pastimes, but now I see that maybe we are hiding that fear by rationalizing that we are striving for consistency.

In short, consistency is a pretty face worn by the fear of change and the unknown so that they can slip back into the discussion, and prevent the march of progress.

So, my advice? Question consistency. Don't let it be a mask for fear of change. Don't let it stop you from moving forward into the unknown.