One of the things that I find most fascinating about software development is the gulf between what we think we do and what we really do. I think that software developers, more than most other professionals, are prone to seeing themselves as "rational actors." We plan, we design, we write code and therefore we have code -- good clean code that is supple, easy to change, and perfectly tuned to what we need it to do.
The thing that we forget is that we are human. We have quirks. And, some of the quirks significantly impact what we produce.
When I've been speaking at conferences recently, I've been asking the following question: Is it easier to add a method to a system or to add code to an existing method? A special bonus points followup question: Is it easier to add a class to an existing system or to add code to an existing class?
Frankly, I don't care what the people's answers are when I ask those questions, but I feel that we can figure out the answer just by looking at the code that is typical in the industry. Many projects have quite a few very large methods and very large classes. In those cases, it was easier to add code to existing structures.
We can go back and forth about why this is the case. My theory is that it isn't the physical act of creating new methods and classes, it's the act of naming. Naming can be rather hard -- just hard enough to try to avoid sometimes. And, well, that could partially explain what we are confronted with.
I don't know what the answer is, but I do know that there might be an alternative to "try harder." To see it, we probably need to develop a much keener sense of how situation alters behavior in development. Something with a basis closer to what Cass R. Sunstein outlined in the book 'Nudge'.
Note: I'll be teaching the first public Brutal Refactoring course in Oslo on Jan 21-22nd, 2013.