[programminggeek]

A lot of programmers don't like/know/care about SOLID or good code design/architecture and also end up complaining when their codebase is a big, huge mess. Often times, just following good OOP principles (and some FP principles) makes it easy to clean up most messes.

The biggest thing I think many programmers suffer from is wanting to have too few objects with big, ugly methods inside.

More objects, fewer methods, smaller methods is often the answer to managing complexity, but it seems like humans don't like appropriately recognizing the complexity of the problems they are working with, even when confronted with the mess they make to solve them.

[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.

[Arwill]

In the real world, these (and other) programming principles are abused to no end. OOP is used blindly as some kind of magic that is expected to produce a good system by itself. More objects, more abstraction is not always good. What will you do when you need to debug trough 5 levels of abstraction meaning 37 levels of subroutine calls just to reach the critical code? What will you do when some guy encapsulates his code in i class as into a black box, but then leaves the company, leaving the class unmaintained? You will still need to deal with it, you will still need to debug through it. And the added levels of abstraction will make it more uncertain where the problem lies. As i've seen recently on a project, the blind enforcing of various OOP principles was responsible for the messy code, i would say 90% of code was in-house made framework/boilerplate, and the important parts were scattered around that. I'm only fan of one programming principle, and that's KISS. Or more precisely i believe that: when you can express something with the programming language directly, don't build abstractions on top of the language to express that thing. When someone else looks at your code, he will only need to know the programming language and read the code, and he will need to learn less about your custom abstractions.

[pjmlp]

On the enterprise, the amount of blue collar developers that don't care is just too much.

Nowadays I try to follow good coding principles on my home projects and the small parts I might have some responsibility over.

But for the overall projects, I don't care any longer. It is just playing Quixote on the enterprise, even more so if the project has outsourced or offshored components.

[nabla9]

The way OO is used in real world, classes encapsulate spaghetti code into smaller chunks. It has been reasonably successful, but good module system can do the same thing.

Personally, I like the Alan Kay's definition:

>OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. There are possibly other systems in which this is possible, but I'm not aware of them.

http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay...