Skip to Content

Random ramblings of an obsolete programmer

No – I don’t think that people are getting dumber as time progresses. But I do think that we are some how not helping the next generation of developers to improve up on what the people who went before them left behind. And this includes ABAP developers.  When I say “we” – I specifically exclude the smart ones who didn’t jump into the holes and avoided the temptations. So all the good and smart people – the stuff below is not about you, and don’t get offended.


Some of you might know that I started my SAP career as an ABAP developer. I have no claims to have been in the league of Thomas Jung or Rich Heilman 🙂 . But I believe I was an above-average programmer. As my career progressed, I moved on to other things – BW, SEM, SD, CRM and so on, but never did leave the “dark side”. And I have been actively mentoring several consultants over the past years, many of whom have ABAP as their core skill. It is my discussions with my mentees that primarily prompted me to write this blog.


In my first SAP project – the server had 500 GB hard disk, and 1 GB RAM. This supported 25 users in a small manufacturng company. The desktops all had 32MB t0 64MB RAM, and something older than the pentium processor. This meant we had to think really hard about the code we created – anything inefficient would never get past the QA box. And we did not have a QA team – the developers could see for themselves when their code was terrible – and would go right back to re-designing the code. There was no code-inspector in the workbench either 🙂 . Of course traces etc were available, and well utilized. Our team leads used to have competitions on who in their team would write the most efficient programs.


Most of us knew some other language before we learnt ABAP. And amongst my peer group at the time – the most common “first language” was C, and Dennis Ritchie was (and still is) God. One of the biggest gripes we had about ABAP was that it did not give us the flexibility that C gave (countless arguments about sort algorithms in C and then a simple SORT command in ABAP). This background in C ( the other popular one was LISP, which unfortunately I never got to learn), and the hardware limitations must have played a significant role in how our coding styles evolved.


ABAP programs mostly followed a procedural paradigm when I started. And then at some point, the OO paradigm started to kick in. By this time, I had started to lead ABAP teams. It was an awfully difficult time for developers to adapt – and people developed a hybrid style. If you had to maintain programs that were developed in this era – my sympathies are with you. Coincidentally, processors had become more powerful, and memory had become cheaper (though not as much as it is today). As a consequence – we had much more powerful servers and PCs, and as a result, we did not have to worry too much about algorithm efficiencies to get the same performance as before.


I did not realize the harm that had set on us, at the time – we just got habituated to write mediocre code. As moore’s law kept proving itself as time progressed, we started going more and more backward in programming. The pathetic part is that we never realized this in time. Since we did not have to worry about quality to the extreme extent like before, we used the time to develop more and more programs and functionality. Dreadful as it might sound – quantity won over quality. We even slacked on peer reviews of code, that used to be second nature for us not that long ago. I believe that this also partly contributed to a decrease in the standard of training that new developers recieved. You no longer needed an internship to start your SAP career – a 6 week training course became a very acceptable entry criteria for developers.


Evidently, I was not the only team lead who realized this. And voila – SAP projects all over started having QA teams who started inspecting code formally. A lot of clients with big SAP footprint started having inhouse QA teams for it, and consulting companies started selling this as a service. I do believe that this helped some – things did get a bit better, but not for long.  If you do anything en-masse, you have to standardize. And QA process became standardized too – and along with the good, came the bad. A lot of QA people I have come to know,  barring a few exceptions, just go through a checklist mechanically, and do not take the time to understand the actual algorithm and offer meaningful suggestions. This is something a developer can do for his own code – and I am not sure if this type of QA really adds a lot of incrememental value.


I have been debating the solution for these issues for a while now – and here are some of the things we seem to get some consensus on.


1. Don’t just train new crop of developers in just ABAP – also educate them in good software engineering practices. It might also be a good idea to train them in a second language if they don’t know it by the time they learn ABAP. It is hard to improve when you have nothing to compare against 🙂


2. Have better benchmarks – somehow show the developer how much better his programs could be. ( A friend of mine, if he has his way, would like to have a QA box which is much less powerful than production for developers to get their code better).


3. Have a compulsory internship with a good senior developer, before some one is allowed to work independently as a developer.


4. Encourage senior developers to take turns and lead the QA teams, and don’t let any one be in QA role for very long.


 5. Encourage debates on programming practices – do not blindly follow something without getting a solid understanding of the arguments for and against. For example –  Offlate, I have not seen many developers who argue against OO as a development paradigm. Infact, the prevailing sentiment is very much against the old procedural paradigms. However, I have heard and read several interesting conversations where people tore the OO paradigm to pieces. It is less important on which side of the debate you are positioned – the important part is to participate, and expand your thinking.


I have one other area that is close to my heart, that I wanted to bring up here – the maintainability of the code we develop. However, I guess I have over stayed the welcome for one web log, so I will defer that to another day.


So, what do you folks think?

You must be Logged on to comment or reply to a post.
  • Hi Vijay,

    I too had same issues you were debating; didn’t know how to solve it. I would say that you have done an excellent job in communicating the problem and more importantly, the solution. Great job!
    I would say that this is probably another version of “The Little SE80 of Horrors”. However your blog identifies the problem and provides solutions.

    Bala Prabahar

  • I enjoy reading ur blogs. And I totally agree with one point .. quantity has won over quality.And also the QA’s role is more or less redundant which mechanically does certain checks.
  • Hi Vijay,

    It seems that there is a real shortage of people who can guide the upcoming developer population. More often then not quantity wins over the quality as you had agreed in your blog.

    Quality should rather be an institutialized Process which otherwise is seen as a patchwork events inorder to cover the audit.

    Organisations should promote more healthy practise of Training rather the what is going on currently in order to achieve the much larger goal to which we all have subscribed to.


    • Totally agree with you.
      There are 2 issues – one, we have a shortage of people, and second – those who are qualified do not always get organizational support and incentives to develop the next gen
  • I started my career in SAP as an abapper also during 2002 / 2003. And I can say I learned it on the way, but with the help of senior programmers very involved in their jobs.
    Now I’m a BI Consultant. I thought over this time, ABAP programming would have evolved so much, but it seems like it has been preserved in stone.
    Sometimes I have to review ABAP programs in ERP and in BI and I wanna shed a tear.
    I have realized that, for example, in my country, developers are recently graduated students, that really don’t like programming but they do the job to be able to get into the SAP world. And as long as programming is consider a sub level job, the bases of this megabig ERP are going to be in trouble… I think that ABAP programming should be a little more considered, as long as programming is the base of any software and is what makes things happen at last.
  • Yes, whatever you mentioned is 100% right. The idea of having an internship with seniors is good and sharing is one of the best things. Example is Open source Unix which is considered the best OS.


  • To Vijay,

    I found that your blog echoed many of the issues that I and my colleagues have experienced more than once, and will probably continue to experience in the future.  I could not agree with your observations more.

    I see that most of the ABAP developers I work with from outside my company have barely sufficient training to qualify as a programmer much less as an ABAP developer.  Within the company I work for we have hired very few new ABAP developers.  I was fortunate enough to get to mentor one of the few who has been hired.  Part of my mentorship is not only teaching navigation of the SAP architecture, but also programming practices for ABAP.  Luckily for me I did not have explain algorithms, software engineering, etc. as my mentee was educated in software engineering.

    Do senior ABAP developers take the time to mentor junior ABAP developers? Or, in this very competitive job market, do they view mentoring  as a ticket to redundancy (e.g. layoff)?  I have the same concern when I work with ABAP developers from outside my company.

    Those of who believe in solid development, ABAP or not, should continue to work with developers who may not have the experience.  I find that working with other ABAP developers on design or performance challenges me to keep up with what is new and to rethink my long held understanding about the language.



    • Thanks Stan. It is an interesting angle you bring up – whether mentors treat mentees as competition. I have not personally seen it in my professional career, but did encounter it more than once in my hobby. 
  • I went from a little COBOL training into ABAP on 4.6 about 10 years ago.  Last year I started learning a little Python, and it has changed the way I see and think about ABAP.

    I agree wholeheartedly that learning another language, maybe just enough to write the Hello World, broadens the understanding.

    Great post! 

  • I agree. Your suggestions are indeed pertinent and useful. As an ABAP developer myself, though quite junior, I found it surprising that many senior floks were least bothered about the performance. Many of the developers’ objects that I had chance to view, review or fix made me cry no ends.

    I believe, there can’t be any excuse to avoid efficient code, whatsoever be the parameters of the production box. Once it becomes a habit, the developer may not be able to construe efficient algorithm in case so the need arise.

    Conventions are fine. They serve their purpose. What is needed, however, is discipline on the part of the developer to stick to the simple premise of writing a ‘machine friendly’ code. That said, it should still be readable for the humans. 😉