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