How to convince “old” co-workers of the merits of OO for certain applications [closed]

Question

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 4 years ago.

Improve this question

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 file
• Do some magic with that data, e.g. do various calculations
• Write out the results into the database or a file again

This 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?

Answer 1

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.

Answer 2

I'm sure this isn't what you want to hear, but you can't. The best you can do is to write your code in an OO fashion (when it's appropriate to) and refactor their code into something OO (again, when appropriate). Some of them will see you moving more quickly and become interested; most won't. Write the best code you can and focus on training new hires. The old timers will retire or otherwise get pushed out eventually.

Answer 3

Considering that the year is 2016, and these guys haven't switched to Object Oriented programming yet, there are two possibilities: Either they don't want to switch, or there is some technical reason that you don't know about that is keeping them from switching.

Either way, you can't convince them.

You should inquire if they have any objections against new code being written as Object Oriented code. There may be the technical reason that object oriented and non-object oriented is hard or impossible to mix.

Answer 4

This is similar to the other answers but what I've seen is that there basically two types of developers: developers that continue to learn new tools and evaluate how they might be useful and developers that learn an approach and stick with it. The reason this appears to be related to age is that new developers will generally learn the current state of the art regardless of which of these two categories they fall into. The key is what happens after that. In 2, 5, 10 years are they still using the same tools and approaches? The other factor related to age is that the developers that fall into the first camp often have opportunities to move into other roles where as those in the second camp don't. There are some developers that continue to learn and choose to stick with development. If you are a new developer and you have the good fortune to work with these people, try to get them to mentor you.

There are likely a lot of people that won't change how they do things no matter what. They have invested a lot of time in becoming experts in the tools they use. Switching to a new unfamiliar tool puts them at a disadvantage and below the level of the snot-nose kids that have been working for a year. Some might be open if you can demonstrate how these techniques help them. If they don't help, it's perfectly rational to not change. There were many 'hot' new ideas that have come and gone in my career and I'm pretty happy I ignored them.

So the upshot is that you should prove to them and yourself that these techniques are actually superior. That's what serious professional does.