1

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?

Kilian Foth
  • 107,706
  • 45
  • 295
  • 310
Matthias
  • 121
  • 3
  • 2
    Dunno, the tasks you described are pretty much exactly the use case that procedural languages were designed to handle, I don't see what OO has to offer for mundane account balancing or report writing. – TMN Mar 17 '16 at 10:47
  • ABAP is not really good at OO, creating an object is 100-1000 slower than calling a form routine. Sorting objects is up to a million slower than sorting a table. I would really like to see the cases where OO makes sense, probably for singletons. – András Mar 17 '16 at 11:20
  • @András I agree that ABAP is not great in doing OO, at least not as good as real OO languages like Java for example. However, in some cases it does make sense to use OO in SAP, for example event-based GUI applications based on Web Dynpro. – Matthias Mar 17 '16 at 11:31
  • 3
    Be open to being convinced that maybe OOP isn't the best approach in this case. Maybe if your coworkers were familiar with StackExchange, they'd be asking the question "How to convince this stubborn coworker that OOP shouldn't be used in our project" :P – Andres F. Mar 17 '16 at 12:08
  • 2
    Asking for a "how to convince someone" or "give me a list of resources" are not really on topic here. [Chat] might be a better place. I would suggest making examples of how OO benefits your project, perhaps with several specific examples - each using OOP and also shown using strictly procedural implementations. If the benefits of OOP exist then this will be clear from your examples and if not... well you will have a hard time convincing them for good reason. – enderland Mar 17 '16 at 12:10
  • 2
    **[How do I explain ${something} to ${someone}?](http://meta.programmers.stackexchange.com/q/6629/22815)** –  Mar 17 '16 at 22:58

4 Answers4

3

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.

RubberDuck
  • 8,911
  • 5
  • 35
  • 44
  • 1
    Upvote. In spades, dude. Caveat: the following is about human nature, not COBOL. ... One time, at band camp, we, a shop of mostly very experienced COBOL guys, were in an Ada course. I was shocked, stunned, gobsmacked that most could not understand what in COBOL are simply non-concepts like typing, scope, and parameter passing. Another time, you should have seen the WTF looks I got when all I did was use "scope terminators" introduced later in COBOL. – radarbob Mar 17 '16 at 18:49
  • I didn't realize you were an ol' timer @radarbob. ++ for staying current. – RubberDuck Mar 18 '16 at 16:03
2

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.

gnasher729
  • 42,090
  • 4
  • 59
  • 119
  • Well, there are indeed some reasons for not switching in any case. As said, SAP still works like in the old days in some cases. On the other hand, in other areas the system kind of forces you to use OO, since the whole framework is writtein in OO. But even in these cases those co-workers don't want to swtich, they simply stick to what they know. – Matthias Mar 17 '16 at 12:41
  • The idea that because it is 2016 and, thus, everything should be OO is a misnomer. There are cases where there are no 'technical' reasons that would physically prevent someone from implementing something in OO but it's a better design to write it in FP. As a trivial example consider the solution to generating the Fibonacci pattern. Yes, you can write this OO but the elegant solution is typically recursion in an FP pattern or knowing the exact formula to figure it out. – Nahkki Mar 17 '16 at 14:01
2

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.

JimmyJames
  • 24,682
  • 2
  • 50
  • 92
2

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.

JeffO
  • 36,816
  • 2
  • 57
  • 124