[nlawalker]

This is really well put. I'm an MS-stack enterprise dev and I frequently see less-experienced developers avoid creating new classes like the plague. I see it in older code of my own as well. I think there are two reasons behind it: the hesitation to "recognize the complexity of the problems they are working with," as you put it, and the incredibly misguided drive towards "code reuse."

My intuition is that in the junior-developer brain, a problem that's big enough to justify using design patterns and SOLID code is a really scary thing that's simply going to take more time than they have. They aren't comfortable with the idea that they can't contain the whole problem in their heads and inside just one or two files, so rather than breaking the problem apart so they can work on one piece at a time, they pick a part of the problem they can start with (usually something involving manipulating strings or very simple models... something that's simple to solve with a couple of methods) and "organically" grow it into more and more methods and shared state until it's bigger and scarier than the problem they started out with!

I've watched people's eyes light up with anxiety as they are introduced to a big and complex but well organized and decoupled solution that contains a lot of classes... the immediate reaction is "What a mess! There are so many files!" Their first instinct is to want to combine things together, thinking that it would reduce complexity or produce some kind of "savings." They will choose tight coupling over "more code" every time, which is ironic because as soon as a problem caused by the tight coupling crops up, the first instinct is to liberally apply more code until the problem is solved.