Modernizing ABAP development
When I first switched from an analyst role to an ABAP development role, my friend who is a .Net developer was surprised and asked me why I would want to develop in such an “archaic” language. Of course ABAP is not an “archaic” language, but it can be if developers are using obsolete statements. I think the term “archaic” is fitting for developments that are not taking advantage of modern ABAP especially considering the below image from Horst Keller’s presentation on Modern ABAP programming at the 2011 TechEd.
I had an ABAP teacher once say that there are some developers out there that may have a resume that states 9 years of experience, but if the developer is not keeping up with developments in the ABAP language they may really just have one year of experience 9 times.
At the company where I work, we have ABAP coding and performance standards to prevent the most archaic of obsolete statements from being used, however they do not require the use of ABAP objects or Modern ABAP and definitely do no apply for old code. When trying to maintain some of the programs from ancient times, I really want to just rewrite the whole thing utilizing all the modern ABAP techniques that I know and sometimes that seems easier than just trying to add more band-aids to make it work with our changing business processes.
Within IT, our goal is to provide world-class solutions to our customers in the business and to keep the total cost of ownership of IT down. That is the reason we implemented SAP in the first place, but I feel that those statements can collide with each other if world-class may mean paying for training to keep everyone up to date on the newest technologies and spending time to modernize custom programs from the ancient past.
So my question is what kind of IT policies are out there to ensure that we are taking advantage of Modern ABAP in our SAP solutions? How much should be dictated by ABAP programming guidelines or should our training program keep everyone up to date and how much do we trust our consultants? Or at the end of the day, does it just matter if it works or not and how we got there?
Please post some comments if you have any experience with this topic. 🙂 Thanks!
SAP seems to port a lot of the Web Dynpro Java apps to Web Dynpro ABAP. Together with modern technologies like Decoupled Infotype Framework, Florplan Manager, Enhancement- & Switch Framework, this opens up a lot of opportunities for those who will embrace this 🙂
Hi Brian,
interesting post.
What comes first into my mind is Uncle Bob's boy scout rule: leave the code always a bit cleaner ( more modern? ) than you've found it.
When I've to make changes to old code ( and there's a lot of it in my customers system ) up to 15/16 year old ( written by myself 😉 ) I always try to work with abap unit tests, introduce separation of concerns ( database leve <-> application logic ).
But this isn't official policy and among my co-workers I'm quite alone with this .
Regards,
Dirk
Thanks Dirk!
I love Uncle Bob's boy scout rule! I think I had a flashback of picking up cigarette butts on our last day at a campsite when reading that... I knew I was supposed to learn something from that experience! Leaving code in a better condition is just the right thing to do and maybe we can't legislate morality through policy..
-Brian
Hi Brian,
You have a good point in your "standards vs education" thought.
In my opinion, it's much more important to keep developers educated on the right way to use a technology.
But you still need the standards to formalize the rules and apply them on quality control.
Otherwise, it only takes 1 non-educated person to break the entire chain.
cheerio
Hello Tom,
Standards formulation and their application certainly works for quality control as long as standards are updated and checked regularly. Who makes the standards and when were the standards last updated matters much. Especially in case of ABAP, I feel standards are dynamic and should be revised time to time. I also feel, standards at times are context specific and not applicable for all scenarios. SAP already provides many means to implement and check quality of developments but how the quality is determined, matters!
Regards,
Kumud
Hi,
I liked it 🙂
You see that everything depends upon our own interest, I try to keep up to date of the new syntax and new options available in higher releases( SCN has helped me a lot, especially Suhas Saha with his informative sap help documents ). Also I am self involved in Webdynpro development 🙂 and implement OOPS when ever possible in ABAP Developments.
The familiar thing is that most reputed clients have their own policies and they just want to stick into the old style of development( by just avoiding the obsolete statements, not using Badi's or enhancements, develop only downward release compatible code 😉 ), we are only allowed to stand for that.
Yes you are true , the feeling while digging the ancient program's ;). I conclude that we have to stay up to date and also work in downward releases.
Kesav
My mantras are "keep it simple" and "don't fix what ain't broken". Learnt that through many years of experience...
It's not about "ancient" vs. "modern", it's about good developers vs. not so good. The fluff like "oh, I am a cool hacker and do only OOP and spit on your internal tables with header line" makes me laugh, quite honestly. Writing "modern" code solely for the sake of being "modern" is not any better than an "ancient" code that works just fine and suits business needs. So I vote for "whatever works best for business". A good developer will always find a balance between "modern" and "ancient".
P.S. Just wanted to point out that on the picture "modern ABAP" looks very proud and confident while "future ABAP" - kind of bloated and about to tip over. 🙂
Sometimes I think "ain't broken" is up to interpretation.
I'm considering spending some time to create a report about program changes. Something to point out if there are problem programs that we are continuously changing. Then we can decide if these programs should be redesigned instead of making continuous small changes.
Exactly, ABAP has been evolving at a great pace since its introduction to programming world. After 5 years down the line, there is no surety that OOP will still be a "cool" concept. We may witness something cooler than OOP.
At my company, we've taken the approach that we have a few experienced full-time employees and proven on-shore consultants who directly oversee the work of our offshore consultants. Although it's not perfect by any means (in fact it can be quite frustrating for the overseers) I think it does strike a good balance. We still have our flexible offshore workforce, who we can increase or decrease almost completely as the workload changes. But the work they do goes through the filter of our on-shore team, who are encouraged to attend training and keep up to date on good practices.
Often for software built for internal use, just 'making it work' is the priority over supportability. The task is tested against it's initial requirements and it lives it's whole life without a change in design. As long as someone takes a thoughtful look at a task beforehand, and determines how important supportability is likely to become, theres room for both types of developers on a team.
I think the key there is having a strong and mature review process and ensuring that the on-shore tam attends training and keeps up to date on good practices. That scenario sounds pretty good.
Personally, I tend to do a lot of the off-shore reviews, which can become daunting when trying to balance with my own large workload. Code reviews are probably my least favorite thing to do.
It helps me to stay right on top of the offshore team. I review their progress and send them feedback every day. Once it became part of my routine it became a good deal easier.
A switch from a business analyst to a developer? Please tell me you have some technical degree and training in programming. This is a major problem with field. Someone learns a few lines of SQL and claims to be a programmer. Being a programmer takes years of training, not just coding, but the foundations of good business practices, ergonomics, database, etc. There are many college degrees for programming. Yet, companies hire "programmers" who have made career switches with degrees from totally unrelated fields of study. For example, a programmer with a degree in Computer Information Systems or Management Information Systems cannot go out and get hired as a chemist. You would be crazy to even interview this person. So why would you hire a chemist to be a programmer, for example. Sometimes it works out. But this type of recruiting can result in bad programming.
Hi Kenneth,
Yes, my major was Computer Information Systems, which was in the department of engineering and included all of the same programming classes as a computer science degree, but also includes a minor in Business Administration. Additionally, I had professional experience doing .net and flex development before making the move.
I agree that programming requires a lot of training, but I also think that a chemist could be trained to be a programmer. Especially if he understood business. Also, a trained programmer who does not understand business may not necessarily be a good programmer in some situations. Of course being a member of Gen Y, I belive I can do anything 😉 http://www.hulu.com/watch/319318/
Great to hear! You are in the minority. And, yes, I have been made aware about the Gen Y'ers.
I personally believe one of the main rules of thumb is to encourage and foster reusability instead of reinventing the wheel. This rule is reflected in many areas of solution development - e.g. in architectural design and componentization, identification of existing functionalities like BAPI's, designing processes+use cases+test cases+test scripts and implementation of low level functionalities in coding.
Modern, standardized technologies and constructs in my and many others' opinion support reusability better across various technologies used today. OO versus classic programming is not really a fair fight reusability wise when looking e.g. at the newer solutions SAP is producing...
So my take on the questions:
- what kind of IT policies are out there to ensure that we are taking advantage of Modern ABAP in our SAP solutions?
* I've deployed SAP Best Built Applications based ABAP guidelines to a few customer sites with good results -> truly recommended
- How much should be dictated by ABAP programming guidelines or should our training program keep everyone up to date and how much do we trust our consultants?
* programming guidelines for low level programming, training for high level design aspects. Trust..hmm..is subjective and its level depends on the programmer:. 🙂
- Or at the end of the day, does it just matter if it works or not and how we got there?
* on the short term (= you just need to get it done with) it doesn't matter, on the long term it definitely does!
At least, it´s all about budget & time.
As a consulting programmer I´am faced with all kind of customer work. From the old list-based programming to OO pattern based work.
My experience is, that normally the customer is not willing to pay for investing into modern programming. The work has to be done quick and cheap.
I think, a bit of more enforcement of SAP regarding old statements / technologies would be good. Just make old techniques obsolete! Then all companies would see the neccessity to train their employees.
As one said before: The weakest link of a chain defines the result of a product.
You're right, it all about budget & time, even for SAP. It would be expensive and time consuming for SAP to obsolete that which they still use in a majority of their own R/3 code base. Just as it would expensive and time consuming for us to retrofit our considerable existing code base to use newer technologies. The reality is that all we can do is make gradual improvements as time allows.
Also, it will always be an expedient practice to copy what already exists, and modify it to suit current needs. In most cases in SAP, that still means copying 'old' technology code to create new programs. In our fast-paced development environment, rarely are we given the time to retrofit these programs to use newer techniques.
I am thinking about some clever mechanism eg "All coding created after xx.xx.xxx has to use methods instead of performs" or "All new packages have to use the package interface".
Something like that.
br
Norbert
I think it would be difficult to implement something like that because of dynamic program generation considerations (i.e. table maintenance generation, SQVI, etc.).
What might be useful though would be a switch setting in the development environment that enforced more stringent rules on the use of older commands and syntax. A good starting place would be to enforce ABAP Object syntax rules on all development objects via this switch setting.
If these settings were then 'protected' by security, it would then take an override by QA to allow the use of the obsolete commands and syntax if needed for some reason. The setting could also be tied to 'released vs. never released' development objects so that it would be possible to still modify and activate existing code, while blocking usage in new development objects.
Norbert, this is sad but true. Probably the root cause of the situation as a business may not see the value in modern programming. However, I believe there is value if it makes the code easier to maintain.
Randy, I really like this solution.
Hi Brian,
I work as a Developer for 14 years now and yet, I'm used to write code without using OO.Meaning that I will use OO to do somethings that in the past I would do with FM but I will not write a whole program OO based.
I will use OO if the scenario requires something that it can't be done with "classic" abap off course.The big difference in my opinion is the way and completeness of the written code. There are programs that are so well written that even after 14 or more years work well and making additions/changes to them is a piece of cake. In the other side as you probably are aware, there are programs written ( independently the "new fashion" way or the "old fashion" way ) that within a month or a year are subject to change cause of performance issues, changes or additions that are to difficult to implement mostly cause of the way that the program is written. I believe that it's not only the tools used, but the more important thing is the person who writes the code.
Have also in mind that programs written a decade ago, are using old techniques,and programs written today will be using old techniques within the next decade.
Finally, I believe that it's more than good to follow the new technologies and take advantage of them BUT the most important is to have the "right" person to do the job.
Regards.
Hi Brian,
I totally agree with you on this. I dont know why are people so scared of OOPS concepts.
I know a developer who still works on only SAP scripts and classical reports with WRITE statements.
I tried to teach, but these people dont want to learn.
As for the future of ABAP, here are some observations:
I hope new developers start using new techniques and encourage others to do the same in a friendly way so that ABAP goes to great heights in future.
-- Manish
Hi Manish,
I like your statement "The re-usability is a part which is only studied in books but not used in practical scenarios." 😆
If they read the books, they will apply it. Some people even don't read the books. Do same thing again again, it's good for them not for good developers.
Manish, looking at Horst's graphic above, I would have placed myself as a Unicode Enabled to Modern event on the evolutionary scale.
But what, pray, is FPM? Can you point me at an all-telling link?
Thanks a mil
Sean
Floor Plan Manager http://wiki.sdn.sap.com/wiki/display/Found/Floor+Plan+Manager
Used with ABAP web dynpro
Thanks Brian - I'm a little less stooped now. Sean
To me, like everything in life, it’s a balance but in this case it mostly comes down to the individual.
An individuals attitude towards wanting to know more is the greatest driver to stay current so I try to help this element.
Internal knowledge sharing, encouraging an element of “try it the new way” and senior developers leading by example create an environment of expectation which helps people develop the right attitude.
As others have said standards and training are part of it too, but at the end of the day a training course and a document are not going to change someone’s attitude.
Good or bad code comes from a developer, support their change in attitude towards what they do and how they do it and you change the outcome.
In saying all that, if it ain’t broke, don’t fix it. – don’t get too hung up on the past, just create quality for the future.
I'm grappling with the modern ABAP/ancient ABAP question as well.
Especially with regard to existing code. I'd love to insist that e.g. the SELECT-ENDSELECT construct (which abounds in our 16 year-old environment) dies the death it deserves. Yet when it comes to maintenance, I have to be cost-conscious and leave changes to the changes that are relevant to solve the problem. This saves development costs and testing costs. Development costs in that the developer does only what is necessary to fix a problem and testing costs in that only the immediate expected change is required to be tested. Sure, if the changes can be isolated to what the tester wishes and is primed to test, I'll insist on further modern changes, but if what I want done extends the testing scope, then I have to swallow hard and accept the gunk.
Then again, I have some clever coders that take late-binding too seriously, for instance they will create a get-data method that entirely wildcards the SELECT, including returned columns, table name and WHERE clause. This denies me the simple where-used function of the workbench and leads SolMan's CDMC/CCLM to believe that particular tables are not used at all.
The question of standards and how far they should reach is always under question. I believe that standards should not deny developers that creative streak with which they are naturally imbued and constrain them from experimenting, yet standards must enhance TCO in terms of robustness of code and completeness of code.
I even 'force' my developers to always test SY-SUBRC after a table read (for instance) even if the functional blokes cannot provide a proper handling. So, to see a statement such as :
IF SY-SUBRC <> 0.
* 12/7/2012 Henry told me this can't happen and doesn't need a response
ENDIF.
is not strange. At least this adds to the documentation...in a way 🙂
Cheers
Hi Sean,
EPC (Extended Program Check) -transaction SLIN- or SE80 -> Program ->Extended Program Check should always be done! It will tell us that what are bad coding, possible bugs even though they are not syntax errors. EPC totally should be green for Errors, Warnings and Messages, otherwise pseudocomments should be used to hide the message and commented in the program.
It helps me a lot to discipline the programmers for doing fine coding.
Hi Tuncay, yes I use SLIN -and on top of that I use SCI/SCII. This allows a bulk evaluation, particularly if you have many objects to work through. If one has many transports to work through, I create a transport of copies and include all the transports into that then test using my transport of copies.
Add to that (I don't work for the company) CodeExpert's Hawkeye/APOD does a similar job, with the added benefit (besides testing deeper than SCI/SCII/SLIN) that it gives reasoned comments as to why a particular coding is less than desirable and hints on how to fix. I'm looking at it currently.
Best wishes, Sean
Hi Sean,
Great. Yes, we need to use Code Inspector too.
I didn't know about Hawkeye APOD. Thank you for sharing.
Thanks,
Hi,
I hope you don't mind me mentioning smartShift's smartDevelop solution since you mentioned a 3rd product name already 😉 .
smartDevelop provides rule based ABAP code analysis and combines it with a unique technology that corrects many of the errors it finds automatically. It is integrated in the task release process (CTS) so coding with errors can never be released.
Albrecht
I did see a webinar about Smartshift after writing this post. It seems like a great product for companies that want to automate updating old code.
-Brian
Hi Albrecht,
If you've already mentioned smartDevelop, I would like to hear some more about your product: What are its main advantages over standard Code inspector?
Thanks,
Shai
Hi Shai,
to keep with the spirit of this section I will keep the description of our offering short. If you want more info please reach out to me via a private message, linked-in, email (agass@smartshifttech.com) or twitter (@albrechtgass).
At the core of our tools is a code parsing and transformation rule engine, that can detect issues (such as CI) and also make changes to the ABAP code - the unique part. We can do this for upgrades, unicode enablement, code/HANA optimization and for on-going code assist for developers.
Albrecht
Hi Brian,
That is correct.It is depends on our own interest.When i started posting my question in scn i got some very good links on various topics.With bapi ,bdc and keeping the code in different style.This will be very useful to upgrade us into new with good features.After i started contributing got very good ideas from ( Kesavdas,venkat.o,Edurado,).Special thanks to them. 🙂
Here some clients can tell what they want exactly but in some cases they will see the final the output nothing else.I think it is our work to make the reports with good performance and make the necessary changes in the old coding.
Good Blog.
Regards,
From observation at my company, exposure to the tools is often not enough. The switch from procedural to OO development takes more than learning how the class interface works or not using certain ABAP statements. I've seen countless times that programs delivered by contractors show that they apply the rules, but still don't entirely get the concept of object oriented development, and use a class as they would have a used a function group / modules, which completely defeats the purpose.
Enforcing rules is one thing, but you better make sure the philosophies behind it are applied too.
Hi Jorg,
you're so right. You can easily write procedural code with OO-syntax.
The shift of the developer's mindset is really the most important and probably most difficult task.
Regards,
Dirk
I think you can combat that with design review sessions. However, if most the team also does not have the OO mindset, that could be counter productive.
I was also thinking a good task for a new developer would be to rewrite old procedural programs to be OO so that they don't learn to write procedurally when looking at existing programs for guidance.
-Brian
Hi Brian,
Good blog resulting in nice discussions above.
We are practicing Clean Code rules, which means that code should be:
These are general rules, which means that no technique is forced. I am fan of object oriented programming and unit tests in place and I practice it actively. But it does not mean that I am forced to use it - sometimes adding simple line to existing spaghetti code is easier and better than rebuilding solution again (less risk).
I want to mention some important rules that suits ABAP development as well:
1. Leave the campground cleaner that you found it
2. KISS - Keep it simple
3. YAGNI - You Aint Gonna Need it
4. DRY - Do not repeat yourself
Regards,
Adam
Great job!
Here at the company where I work, earlier this year, took place upgrade EHP6 with SP2 ABAP component. We noticed many differences, and even some that were already available but no one had discovered ...
If you want to make SAP things purely clean, the best way is to redevelop all old SAP applications from the scratch, using features from last version NW. At any other way rare code always will be "dirty" and breaking your rules.. GOOD LUCK. .
Regards
Sergii
Hi Brian, thx a lot for your blog. All the comments are very interessting. Coming back to your point ...
"So my question is what kind of IT policies are out there to ensure that we are taking advantage of Modern ABAP in our SAP solutions? How much should be dictated by ABAP programming guidelines or should our training program keep everyone up to date and how much do we trust our consultants? Or at the end of the day, does it just matter if it works or not and how we got there?..."
I'd like to add: We have a lot ofe rule, tipps and tricks, we put all the stuff into "developement guidelines", which are updated twice a year and it is one of countless "offcial" document. We also have to check the reports / programs of external consultans and if they had worked according to the rules. But this is in deed time consuming. Nevertheless we could improve the qualtiy of the reports dramatically. We like to work with the same consultants if possible. So they know, that we will not accept any "dirty coding". but we also had to face what was mentioned by others: time pressure leads to coding that is not really following the guide lines. One other important thing we discovered is, that we have to learn about the different ways the consultants work. So some "tricks" we saw lead us to the next adjustment in our guideline. Let's resume: we are working hard to reach the level "perfect" but I'm pretty sure we will only get closer but we will never reach it 🙂
all the best
Matthias
Hi.
Look here for results of such modernizing form SAP http://scn.sap.com/community/abap/blog/2013/02/24/sap-continues-disrupting-itself?utm_source=twitterfeed&utm_medium=twitter
Regards
Sergii
Hi Brian,
The documentation is seams good blog resulting in nice discussions.
Thanks and Regards,
karthikeyan
Found this blog post via some "related post" - and only when I read into the comments I noticed that it's old already - it could have been posted today, I think!