Folks,
Every SAP customer that employs ABAP developers has some sort of internal development guideline document. In over 16 years of SAP career, I have seen many of them and most are… how do I put this? Rather misguided. While preaching code optimization, reusability, keeping up with new features, the guideline documents themselves are not following those principles.
How can I tell the guidelines are bad without reading them? Easy: they are more than 20 pages long.
We all know about “best practices” in SAP world and every developer (and even some IT managers) are aware of the advantages of reusing common code libraries, open-source solutions, etc. But when it comes to ABAP guidelines, SAP customers seem to insist on reinventing their own special bicycles.
Every SAP customer wants ABAP programs of the best quality. So, why the way to achieve that for you would be significantly different from thousands of other SAP customers? There is no “why” because it is not different. As someone who recently switched sides from customer to consulting, I will let you in on a secret: 90% of the corporate ABAP guidelines repeat the same information.
Lead by example and consider incorporating these public resources by reference rather than by value:
“YOU sHOUld noT puT SELECT iN A lOoP”. Gee, thanks for the tip.
It does not matter how valid this rule still is. Development guidelines are not a replacement for baseline training and ABAP 101 material does not belong here.
These days, ABAP keyword documentation explains quite well how the commands work (believe me, it is a huge improvement from the early 2000s when documentation was randomly sprinkled by text in German). The examples of optimized code provided by SAP are available right in the ABAP Editor. If this is not enough, SAP Press and other publishers offer the books for a wide range of ABAP developer audiences: from complete beginners to experienced ones looking for latest and greatest.
One might ask: but Jelena, what do we do if the developers we employ just keep doing these silly things, such as placing SELECT in a LOOP? Simple answer: this is not the issue that will be solved by copy-pasting ABAP documentation into the internal development guidelines.
Every developer needs to have some ground knowledge before they can begin work. This is not different from any other profession. The ABAP beginners and Junior Developers need to have guidance, mentoring, and support available to them while they are still learning. If more experienced developers are having trouble, we have tools (such as ATC) that perform baseline code quality checks and can be executed automatically. And in the extreme cases, well, as Ron White said, “you can’t fix stupid”.
“Thou shalt not JOIN more than 5 tables”, “terrible things happen to those who write lines longer than 72 characters”, “BINARY SEARCH is great” (puh-lease), and other ABAP urban legends fill the pages of too many corporate guidelines. Right next to them, lie the great relics: recommendations on proper practices in creating module pools and functional modules. Indiana Jones would have a field day here!
ABAP guidelines should guide the developers how to write programs today, not in the last century. The only guideline on functional modules should be that they need to be created only in a few cases and should call a class method. And if you are still creating module pools, well, then quality of guidelines is probably the least of your worries.
As Leonardo da Vinci said, “simplicity is the ultimate sophistication”. KISS principle in development is one of my favorites and there is no reason why the development guidelines should not follow it too. With this in mind, I present to you Jelena’s Nice and Simple Corporate ABAP Guideline Template (tm).
Total: 10 pages maximum
This section is for the IT managers who might have trouble understanding specific benefits of Jelena’s Template and how exactly it translates into value for the stakeholders.
I hope that one day the corporate ABAP guidelines will do what their name suggests: guide, or even inspire, the developers to create better programs instead of serving as the ABAP Penal Code equivalent. In the meantime, whenever you encounter a monstrosity of a guideline, discreetly slip this link to the person in charge: https://github.com/Jelena-P/NiceABAPGuidelineTemplate Hey, it’s open source and free, so how could it possibly be bad? 😉
Disclaimer: this blog represents author’s personal opinion and not an opinion of SAP or my employer. This post is not based on any single organization and any resemblance of real guidelines is purely coincidental.
Every SAP customer that employs ABAP developers has some sort of internal development guideline document. In over 16 years of SAP career, I have seen many of them and most are… how do I put this? Rather misguided. While preaching code optimization, reusability, keeping up with new features, the guideline documents themselves are not following those principles.
Reusability
How can I tell the guidelines are bad without reading them? Easy: they are more than 20 pages long.
We all know about “best practices” in SAP world and every developer (and even some IT managers) are aware of the advantages of reusing common code libraries, open-source solutions, etc. But when it comes to ABAP guidelines, SAP customers seem to insist on reinventing their own special bicycles.
Every SAP customer wants ABAP programs of the best quality. So, why the way to achieve that for you would be significantly different from thousands of other SAP customers? There is no “why” because it is not different. As someone who recently switched sides from customer to consulting, I will let you in on a secret: 90% of the corporate ABAP guidelines repeat the same information.
Lead by example and consider incorporating these public resources by reference rather than by value:
- SAP ABAP Programming Guidelines (use Google search to find these for your ABAP version, this example is for 7.53)
- DSAG Best Practice Guidelines for Development - in my opinion, this remains one of the best resources for ABAP developers
- Clean ABAP – ultimate and ever-expanding open source ABAP style guideline
Devsplaining
“YOU sHOUld noT puT SELECT iN A lOoP”. Gee, thanks for the tip.
It does not matter how valid this rule still is. Development guidelines are not a replacement for baseline training and ABAP 101 material does not belong here.
These days, ABAP keyword documentation explains quite well how the commands work (believe me, it is a huge improvement from the early 2000s when documentation was randomly sprinkled by text in German). The examples of optimized code provided by SAP are available right in the ABAP Editor. If this is not enough, SAP Press and other publishers offer the books for a wide range of ABAP developer audiences: from complete beginners to experienced ones looking for latest and greatest.
One might ask: but Jelena, what do we do if the developers we employ just keep doing these silly things, such as placing SELECT in a LOOP? Simple answer: this is not the issue that will be solved by copy-pasting ABAP documentation into the internal development guidelines.
Every developer needs to have some ground knowledge before they can begin work. This is not different from any other profession. The ABAP beginners and Junior Developers need to have guidance, mentoring, and support available to them while they are still learning. If more experienced developers are having trouble, we have tools (such as ATC) that perform baseline code quality checks and can be executed automatically. And in the extreme cases, well, as Ron White said, “you can’t fix stupid”.
Ghosts of ABAP Past
“Thou shalt not JOIN more than 5 tables”, “terrible things happen to those who write lines longer than 72 characters”, “BINARY SEARCH is great” (puh-lease), and other ABAP urban legends fill the pages of too many corporate guidelines. Right next to them, lie the great relics: recommendations on proper practices in creating module pools and functional modules. Indiana Jones would have a field day here!
ABAP guidelines should guide the developers how to write programs today, not in the last century. The only guideline on functional modules should be that they need to be created only in a few cases and should call a class method. And if you are still creating module pools, well, then quality of guidelines is probably the least of your worries.
This is The Way
As Leonardo da Vinci said, “simplicity is the ultimate sophistication”. KISS principle in development is one of my favorites and there is no reason why the development guidelines should not follow it too. With this in mind, I present to you Jelena’s Nice and Simple Corporate ABAP Guideline Template (tm).
- Introduction (1-2 pages). Outline your company’s strategy, principles, what your guidelines are meant to achieve and how they add value.
- Naming conventions. Note any peculiarities (for example, some companies use special IDs in the package or object names). If this section takes more than 2 pages then you are doing it wrong.
- References (links) to SAP / community guidelines and a reminder to RTFM. 1 page
- Developer tools. Do not copy from SAP Help, only note anything specific to how your organization uses them and if any third-party tools are also in place. 1-2 pages
- Any requirements specific to your organization. This can include industry-specific compliance, accessibility requirements, and such. Up to 3 pages.
Total: 10 pages maximum
Business Value
This section is for the IT managers who might have trouble understanding specific benefits of Jelena’s Template and how exactly it translates into value for the stakeholders.
- Stating the obvious here but compare 100 pages vs 10 x how many consultants you engage x reading time x billable rate = pure, quantifiable cost reduction.
- By referencing SAP and community guidelines and best practices, you do not only make your own document shorter but also get coveted “automatic updates”. Community keeps the guidelines fresh and updated for free. The only part that your team may need to review is the 10 pages of the template. So, 90 pages x time it takes to review and discuss x hourly salary… You know the drill.
- Simpler rules are easier to check automatically and enforce. This leaves more opportunities for the development teams to work on innovative design, collaborate, and share knowledge instead of having a quarrel about a variable prefix that is not in compliance with the rules from page 63 of 156.
Conclusion
I hope that one day the corporate ABAP guidelines will do what their name suggests: guide, or even inspire, the developers to create better programs instead of serving as the ABAP Penal Code equivalent. In the meantime, whenever you encounter a monstrosity of a guideline, discreetly slip this link to the person in charge: https://github.com/Jelena-P/NiceABAPGuidelineTemplate Hey, it’s open source and free, so how could it possibly be bad? 😉
Disclaimer: this blog represents author’s personal opinion and not an opinion of SAP or my employer. This post is not based on any single organization and any resemblance of real guidelines is purely coincidental.
- SAP Managed Tags:
37 Comments
| User | Count |
|---|---|
| 5 | |
| 5 | |
| 3 | |
| 3 | |
| 2 | |
| 2 | |
| 2 | |
| 2 | |
| 1 | |
| 1 |
