I am working as SAP developer, where in many cases you have traditional requirements to applications (reports):Read in some data from the database or a fileDo some magic with that data, e.g. do various calculationsWrite out the results into the database or a file againThis is the typical use case for many SAP programs, as it has been for about 30 years now in that area. However, in recent years even SAP becomes more and more modern, with web-based (HTML5) interfaces, Java support, mobile apps, and last but not least a reasonable OO version of the main programming language, ABAP.Coming from the Java world for me it's obvious to prefer ABAP OO over plain procedural ABAP in many cases. However, as often in the SAP world, there are many older co-workers that are used to that old precdural programming style, they have never learned any OO programming. So my boss asked me to explain OO in general to them, and in which cases it makes sense to use it rather than the old style.So I did this, organised a workshop, and explained all that. However, even though it seems most of these collegues have understood what OO means in general, what classes and objects are, inheritance, the whole thing, they still just don't use it. For them it seems convenient to stick what they are used to to, as this is what they have used since dozens of years.Now I don't want to convince them to use ABAP OO in any case, as in SAP sometimes it does make sense to use traditional procedural approaches. However, as with modern SAP application OO does make sense in many cases, I would like to make my co-workers life easier by convincing (not forcing) them to use OO in these cases.Can you recommend any arguments why in general OO does make sense in some - practical! - cases, even if you are used to procedural programming since 20+ years?
How to convince old co-workers of the merits of OO for certain applications
object oriented;procedural;sap;abap
I think your question goes beyond some magical explanation as to why OO is better. In fact, that question has already been asked on this site.You made a management mistake. You can't take a complex subject, do some minimal training with not follow-up or management buy-in and think you're going to get people to change the way they do things when there is no immediate incentive.Are there going to be code reviews that have management support to start providing negative consequences for not complying? At what point will it be unacceptable to check in code that is not done in OOP when appropriate?Will additional training be offered? Will more time be offered to complete some tasks? One benefit of OOP is to help maintain complex code. It will take longer to write. Who is willing to slow the current development in hopes of limiting technical debt?I like learning new things, but they take time and don't immediately show up in production code for my job. There are occasions when I can step back and evaluate what I'm doing and architect a better solution. Sometimes, there's someone constantly looking over your shoulder to put out a fire and the latest and greatest new shiny stuff has to sit in the box.Don't give up! Focus on some early adopters. Find a new piece of code to write and team-up with everyone and see if you can design it differently. Don't worry if it never gets into production, they're learning.Eventually, they will be forced to revisit code that was designed with more OOP principles and they may finally see how much easier it is to work with, debug and expand. It will take time and time is very valuable. 