Put SAP Dev Tech Radar On Your Radar * ABAP Loves Words, And I Love That * Women in Tech: 2024 Edition * SAP.iO vs Math * You Should Actually Test Stuff * OOP Video Recs
OOP is at the core of most problems of the industry.
I am not a developer, but I work with closely with developers von 2 decades. Normally I wouldn't care what paradigm developers choose. However, when they started OOP in ABAP things went downhill. Development times went up. Code quantity went up and code quality went down. Design patterns which solve problems of OOP but solve zero problems of outside world became fashionable. Now developers could spend their working time in boilerplating the same design patterns over and over again without solving the users problem and being confident of their competence at the same time (which in my sense makes OOP so attractive for developers).
"This can not be changed anymore" became a more common problem than in the times of imperative programming. Presumably mostly because the object model would have needed to be refactored before implementing the change or the carefully selected design pattern du jour did not fit. "Refactoring" is anyway another problem only introduced by OOP.
With OOP code became more obscure, complexity of runtime behavior became high, debugging more difficult, hence more bugs. Since it became increasingly impossible to create reasonably bug free code, mandatory tests were introduced to solve next OOP related problem. It is generally a bad idea to test quality into a product instead of trying producing good quality from the beginning. But here you go.
10 years ago, I spend 80% of my discussions with developers on business need. Nowadays I discuss 80% of time technical issues. The absolute amount of time spend on the business needs did not change though.
OOP is an expensive experiment which needs to end. Only that SAP came to the idea to make in mandatory.
I've been observing developers for a very long time, just like you. There are some things specific to OOP within SAP development (at customers, can't speak for what goes on inside SAP offices). First, we are usually limited from the start because we work within SAP constraints. We rarely get to create our own design and because of that, we rarely get practice, so when we finally get a chance, it can be "oh s*t, what now?" moment. You need to practice development and design to be any good at it.
Also, SAP never produced any good training material on best practices of applying OOP for SAP developers. Even looking at SAP's own code, it's like Wild West out there. Some stuff I'm looking at and can't understand what was the creator thinking. Some things are quite elegant though (SAP Gateway is rather cluttered but overall I think it's a good design). And you must remember how SAP training used to be pretty much non-existent in general back in the days. It was very difficult to find any information. So we started with a handicap and I think never really recovered from it.
Another thing I've noticed is for some reason some developers seem to feel pressure to start engineering something complicated when something much simple would do. Even in the old discussions of "procedural vs OOP" on SCN many people admitted that there are tons of very bad object-oriented code out there and good procedural code is better than bad object-oriented one. And that also leads to the "broken window syndrome" when garbage gets added on top of garbage because it's already been there.
This may be controversial but personally, I favor "OOP light". I don't over-engineer the classes and follow what is practical and, most importantly, what can be easily understood and maintained by an average developer. I've seen good original design butchered by later changes just because the person clearly didn't understand the original idea. One might say well, it's a problem of that fool. But to me, it's not more important to be right or "proper". If my awesome design doesn't seem intuitive to others, is it really that awesome? I've had much more success with this practical approach than anything else.
About "refactoring" - maintaining procedural code is in no way less difficult than object-oriented. For starters, you can independently change methods in the same class but as soon as one person locks a procedural program, no one else can work on it. And I view refactoring as positive and not negative thing. Code is not written in stone, it's more like a living organism. It needs to be maintained, sometimes pruned, sometimes renewed. If someone's object-oriented code does not allow for that, then it's indeed a problem.
There is a saying "don't hate the player, hate the game". I think the opposite is true for OOP. Plenty of bad players. :)
OOP is at the core of most problems of the industry.
I am not a developer, but I work with closely with developers von 2 decades. Normally I wouldn't care what paradigm developers choose. However, when they started OOP in ABAP things went downhill. Development times went up. Code quantity went up and code quality went down. Design patterns which solve problems of OOP but solve zero problems of outside world became fashionable. Now developers could spend their working time in boilerplating the same design patterns over and over again without solving the users problem and being confident of their competence at the same time (which in my sense makes OOP so attractive for developers).
"This can not be changed anymore" became a more common problem than in the times of imperative programming. Presumably mostly because the object model would have needed to be refactored before implementing the change or the carefully selected design pattern du jour did not fit. "Refactoring" is anyway another problem only introduced by OOP.
With OOP code became more obscure, complexity of runtime behavior became high, debugging more difficult, hence more bugs. Since it became increasingly impossible to create reasonably bug free code, mandatory tests were introduced to solve next OOP related problem. It is generally a bad idea to test quality into a product instead of trying producing good quality from the beginning. But here you go.
10 years ago, I spend 80% of my discussions with developers on business need. Nowadays I discuss 80% of time technical issues. The absolute amount of time spend on the business needs did not change though.
OOP is an expensive experiment which needs to end. Only that SAP came to the idea to make in mandatory.
Thank you so much for a thoughtful comment!
I've been observing developers for a very long time, just like you. There are some things specific to OOP within SAP development (at customers, can't speak for what goes on inside SAP offices). First, we are usually limited from the start because we work within SAP constraints. We rarely get to create our own design and because of that, we rarely get practice, so when we finally get a chance, it can be "oh s*t, what now?" moment. You need to practice development and design to be any good at it.
Also, SAP never produced any good training material on best practices of applying OOP for SAP developers. Even looking at SAP's own code, it's like Wild West out there. Some stuff I'm looking at and can't understand what was the creator thinking. Some things are quite elegant though (SAP Gateway is rather cluttered but overall I think it's a good design). And you must remember how SAP training used to be pretty much non-existent in general back in the days. It was very difficult to find any information. So we started with a handicap and I think never really recovered from it.
Another thing I've noticed is for some reason some developers seem to feel pressure to start engineering something complicated when something much simple would do. Even in the old discussions of "procedural vs OOP" on SCN many people admitted that there are tons of very bad object-oriented code out there and good procedural code is better than bad object-oriented one. And that also leads to the "broken window syndrome" when garbage gets added on top of garbage because it's already been there.
This may be controversial but personally, I favor "OOP light". I don't over-engineer the classes and follow what is practical and, most importantly, what can be easily understood and maintained by an average developer. I've seen good original design butchered by later changes just because the person clearly didn't understand the original idea. One might say well, it's a problem of that fool. But to me, it's not more important to be right or "proper". If my awesome design doesn't seem intuitive to others, is it really that awesome? I've had much more success with this practical approach than anything else.
About "refactoring" - maintaining procedural code is in no way less difficult than object-oriented. For starters, you can independently change methods in the same class but as soon as one person locks a procedural program, no one else can work on it. And I view refactoring as positive and not negative thing. Code is not written in stone, it's more like a living organism. It needs to be maintained, sometimes pruned, sometimes renewed. If someone's object-oriented code does not allow for that, then it's indeed a problem.
There is a saying "don't hate the player, hate the game". I think the opposite is true for OOP. Plenty of bad players. :)