Thought of writing the blog the share the most common issue after a SAP maintenance project is handed over or when new consultants come into the project. The first few days there are high level descriptions/discussions of what's there in the landscape and what not. Then comes the hard part when bugs or tickets or incidents starts coming in. Then the effort taken often to understand the process is often painstaking due to lack of code comments or documentation(In code and as specifications) and usually ends up taking more time compared to what might have been used if it was done in the first place :smile:
Little comments in the code if they are missing often don't reap the benefits immediately but always help in the long run. The missing comments are like small amounts of C02 that eventually causes water levels to rise and thus flooding or temperature swings..(when you manager is chasing you solve an incident or an issue and you don't have enough time to dig through the layers of custom code and hope that some documentation or comments would have helped) and the effort to do it later is much more effort-intensive.
Now people might think what it has to do with say I create 1 Z-Report or 1-Function module or Just activate a BADI and write a small snippet of code. But in the long run artifacts or objects gets added over the years, remember business that use Z-process would not change often and keep doing even more customizations. I had the experience of working with such clients. They install SAP and then create Z-Transactions to fit in business requirement, :???: might sound crazy and stubborn but the logic often given is I want my business to run my way not always the way what SAP says( suits them as they are one of the BIG 5 consulting firms :grin: ).
The other thing is now we get many versions of SAP modules and categories and often many scenarios and modules and processes and business practices are not always accounted for in standard SAP packages or often come later after SAP starts delivering it for such and industry. Such things are validated by the various solutions SAP has delivered from time to time. Like access of SAP clients shifted from Desktop client in its early years to web-based and now moving to cloud based to many new modules introduced over years to get into various industry segments.
Now how can small comments help in the log run..
Well the small comment that you write and may be leave the project will always help the other consultant coming in and trying to do some changes or add on code or comment out logic. I know the other aspect is people will say what about requirements and design documents. Well they are often done in a bare minimum way and often its not there. Another scenario is often say an age old documentation of a report of Module pool screens exist but the programs might have changed several times over years and the initial logic parts might have changed or many new features might have been added and that's not there in the documents. Such things often take more time as the developer has to understand the feature and then do any further changes.
The other most common scenario is copying BAPI or Standard FM's and then not doing any documentation. Specially with lots of flag fields and generic structures. If large code blocks and nested Z-objects are there they often raise the efforts to understand the code( I remember the days without the new editor and debugger :sad: ) .
Imagine how bad the demo programs will be provided by SAP, had they missed out on the comments :smile: I am sure few runs and debug would be required to know what's happening.
Often small comments and documentation set the pitch for quick understanding improves code readability and thus improving maintainability. Remember when you clicked the documentation button and it said only available in DE :smile: and then translated then via translation tools or sites in internet. :grin:
With the future going OOPS. Its good to have class and methods commented and documented as they are complex objects and say a Z-class with Z-methods if not documented can be hard on people following up with changes or additions to the same. Basic comments or on use of class and methods will always help.
So small missing documentation or comments can make a simple custom development look apparently complex. If present and done on the time development or changes are done can save a lot of effort for future and help improve code readability and maintenance.
So, follow the rule of always commenting or documenting even though it looks useless its good in long run. So ending this blog with few links on documentation.
http://help.sap.com/saphelp_40b/helpdata/EN/c8/19764e43b111d1896f0000e8322d00/content.htm
http://help.sap.com/saphelp_nw04s/helpdata/en/cf/fa40424319b16be10000000a155106/content.htm
http://help.sap.com/saphelp_erp60_sp/helpdata/en/43/b46c4853c111d395fa00a0c94260a5/content.htm
Cheers,
Arindam
