Worked on a number of different projects clearly from a maintence perspective. From C,C++ mostly around VBS2/VBS3 (Operation Flashpoint) and VSS Simulation systems. Moved on from C/C++ simulation market when the money wasn't really in it unless you're the sales people or upper management. Kind of drives it home when you bike into work and all management are driving BMW ect.. This was a startup that I took a major pay cut.
After that phase moved into web development. Tomcat/Java and Servlet containers and C# and F#. I've spent about in total 12 to 15 year's software development in this field.
When I first started programming I learnt from Quake/Doom Engine from John carmack. I can attest his software style and technical finesse was something to be admired even to me today. There was something to be said to have a look at good written C code that was really straight forward and easy to follow. At this time OOP/Java was starting to become a mainstream in the market place and most of hype and push was from marketing and also compiler writers/contracts wanting to push their contracting sales pitch at Universities/Schools and management.
Granted the whole OOP/Java was one giant experiment that paid off for other people but never really paid off for me. In my younger years I remember not getting OOP. When I say NOT getting it, I never really felt there was a clear explanation of what OOP was and my gut feeling was the whole theory vs practicality didn't work for me. So seeing that I had to time to waste I started research and reading as many OOP books as I could find. In total I've read about 60 different OOP books and research papers. After all this I still conceptually don't GET OOP. The whole thing a act in cognitive dissonance for me.
You probably GOT OOP but I never did. So more power to you.
My only anecdotal (Single data point) experience has been maintaining a large range of different type of software over the years. From procedural code, to functional programming all the way Java, and Spring (Inverse Version Control).
A lot of smart people than me in in the 90's/2000 created these massive taxonomy systems. Multiple inheritance from anything from 10 to 15 layers deep. Excessive use of design patterns and over-use of meta-programming where meta-programming (really) didn't need to be used all the time (look at you C++). I remember night tearing my hair out because these things TOOK up the fucken wall. Litterally the taxonomy's was just that large that had so many inter-layered derived class calling Derived classes that called in turn called the base classes then would in turn call the Derived classes, that would then in turn call some event handler. Yes you get the picture.
It did take about 3-4 years of 10 hour nights to finally get this massive inheritance system (Operation Flashpoint btw) where you could be productive. Then two months after I quit.
I then moved over to Java, and web-app development. Where I doubled my wage overnight. The Java project's designs had also drunk the kool aid also during the 2000's. So yet again I was faced with 7 to 8 layer (Single) inheritance system. Each consecutive developers building on this inheritance system. As you can imagine, the cost/turn around time and budget for such a system caused then to drop the system. They settled on Spring and dependency inversion control.
Granted most of the code I see teams writing is a throw back to procedural code. You have your controller that processes requests that in turn passes it off to services. That in turn accesses Repositories. This is inclusive of your typical MVC model, but most of the services, and code now I see is just a singleton instance of the class that just acts as a namespace for functions.
Prior to this in java land, all enum's and statically allocating arrays where bad and unclean. DIK_CODE's or id identifiers where discarded into the rubbish. Replaced by developers using inheritance type system to replace such crude (primitive) approaches of programming! Looks at all those enum's lets replace them using the type system of the language!
So for example instead of writing.
#define CUSTOMER_PAGE 1
#define CUSTOMER_CHECK_OUT 2
#define ORDER_FORM 3
You had developers using the type system in its replacement.
class Validator impliments IValidator
class Orders extends Validator
class CustomerPage extends Orders
class CustomerCheckOut extends Orders
class OrderForm extends CustomerPage
Somebody is going to come here and proclaim `they were doing it wrong`. I just shrug my shoulders and say it doesn't really matter I'm stuck looking at this mess.
For today, I see developer and new projects coming online where they've moved away from such inheritance model's and moved to a more procedural approach and flat design. I do welcome this move, and cheer for the faster turn around time.
It takes me on average when faced with new projects that use massive inheritance structure's 4-5 days to get my head around the system (If at all). The same or more complicated systems using procedural old statically defined array, enum's and defines take about 1 hour to find and isolate the problem and fix.
Other teams may have had success with large scale OOP code-bases. Though I've mostly found them to be error prone, more riddled with edge case situation and bugs. They're a nightmare to extend (counter to the whole notion of the sole reason for OOP), than your typical on this ID do this approach. It's something to be said I've recently started doing development work on mmpeg and x264 code base and its a please to be up to speed and doing some productive work within 2 to 3 hours.