Skip to Content

Sustainability Checklist for ABAPrs

As an ABAPr it is sometimes difficult to make time for things that may not affect us directly, or, may not affect us for a long time to come. Especially, when we consider aggressive deadlines and the long list of priorities that we always have before us. So, how do we take action and promote sustainability as ABAPrs? I suppose that having a sense of compassion for humanity is a great motivator, without it, we will be challenged to make anything green at all. So I decided to create a very short ABAPrs sustainability checklist. Can we answer yes to these questions when we have completed development on a program?

Does our code have Value?
When designing and testing our code, we should always ask ourselves if the logic would be as good in the long run as it is right now. And, we should always consider any options available to us in creating a low-maintenance, energy efficient program. We can add value to our code by reading blogs, browsing the forums, and keeping our fingers on the pulse of sustainability in SCN. Programs which are structured, commented, and documented, are quite valuable, especially in terms of supportability. Technically, we should be using objects, shared memory, and using, or pushing for, newer WebDynpro methods. Sure, we can write a quick program that saves money for today, but an unstructured, uncommented, and cheaply written program will forever cost any company money in the long run.

Is my code Environmental?
One great way to see if our programs are energy efficient is to use Code Inspector. Randolf Eilenberger has written some great stuff on Code Inspector in the SCN blogs. When we are finished with development, have we documented what we’ve done and loaded the reference into an online repository, or other, where it can be shared? KM, Knowledge Management, is the buzzword of today. Some companies have even hired CKOs, Chief Knowledge Officers. Sharing promotes sustainability among any circle of ABAPrs. I have found once I share, others will follow. We must always try to stay approachable, and open-minded when helping our fellow programmers.

Am I considering innovative ways to develop my code?
The trick with this concept is that we sometimes are faced with a learning curve when using new ABAP methodology. Of course, the customer comes first. When we see a better and less expensive way to do something, but know it will take longer, we need to fortify the customer’s value when explaining to management our motives. We can list A, B, and C, as great reasons that the extra time spent now will save the customers, and the company, a lot of future expenses. We cannot plainly say, “Hey, this is a new idea I want to use, but it’s going to take longer.” If we have a sincere desire to improve, and preserve, we sometimes need to step up and state a case to management. Believe me, if stated properly, they will not only honor your thinking, you could end up a hero. And, don’t be afraid to share new ideas.

Am I passionate about my code?
If this question sounds a little overdone, then you are probably not passionate about your code, or your job. Without passion to improve, excel, and succeed, we will never be able to really see the incredible results that having a thirst for improvement can bring. To be passionate about our code we have to be hungry to learn, and driven to share what we know. We can all spend a lot of time developing in front of our PCs. But today’s ABAPr needs to get out of the chair a more than they use to. We need to collaborate, innovate, support, and also have a bit of emotional intelligence when it comes to today’s ABAPr.  

Is my code compatible?
Will the code we write for one purpose have the capability to be re-used? Can it be plugged into additional functionalities? Or, is it a one hit wonder? The more compatible it is, the more sustainable your SAP network will be, thus saving future costs. If you have an Android phone, a PC, an Ipad, and use google utilities, then you have experienced incompatibility at its finest. If our programs are not compatible, then it will take the same amount of fortitude to reuse your code as it does to sync up your Mac, Droid, and Google stuff.  

“Concentration is inspiration. You must be completely overtaken by your work and your subject.  Only then do all your influences and experience come up to the surface.”    -Cesar Chavez

You must be Logged on to comment or reply to a post.
  • This is an eye washer blog for lot of ABAPr in this time. I have not seen this kind of rightly articulated blog for long time…Thanks a lot for giving us to re-think on our coding.
  • I agree with tools like Code Inspector and Extended Program Check, but I feel documentation within the program IS sufficiant – network documentation is a waste of time and gets out of sync very quickly. Program documentation on the other hand gives one an overview at first glance in the “header” along with a maintenance dated trail. In addition, single line documentation above every code block is comprehensive.
    As for explaining the value in the extra time spent? – that’s not going to make customers add time for documentation and “intricate big picture designs” in an aggressively competitive market. So within the timeframe available you don’t have a choice, but to churn out the code as quickly and effectively as possible. This does not mean the code lacks good design, it’s just not possible to always design for example code with cool inheritance and polymorphism. For this to work you need to have longterm SLA’s with your clients and then it is possible to build cooler, OO objects.
  • I agree with your checklist, and I can’t think about doing my everyday coding without thinking on those topics.

    However, it’s sad that most people doesn’t care about what they’re doing, and just want to deliver things asap, no matter what… But those strong words can hit those people.

    We definitely need blogs like this one in our ABAP community. Thanks for sharing!