Paul David Hardy - Improving the Quality of ABAP Code: Striving for Perfection

Any source code or other supplementary material referenced by the author in this book is available to readers on GitHub via the books product page, located at www.apress.com/978-1-4842-6710-3 . For more-detailed information, please visit http://www.apress.com/source-code .

In 2015, the American SAP Users Group (ASUG) wanted my opinion on a new survey that had been put out by a company called CAST, which had analyzed about 70 large custom ABAP applications from organizations all across the United States and Europe and come to the conclusion that all that custom code was a load of old baloney, ludicrous, rubbish, hopeless, and fit only for the dustbin.

The clear implication was that the ABAP programmers who had written these applications could not touch their own nose, let alone write a program containing even one ounce of quality. Nonetheless, the programs workedthey solved the business problems they were created to solve.

How can this be? How can we get to the stage where 100 percent of code is no good and yet 100 percent of code appears to work? It is because the two things are unrelated to an extentbut only to an extent.

What is meant by the codes being no good is that the analyzed programs were big balls of mudprone to breaking for no apparent reason, and so complicated it would be impossible for any programmer other than the creator (and often even the creator) to understand what was going on and how to fix things or make a change. Sadly, this did not surprise me at all.

This book is aimed at all ABAP developers, whether they started yesterday or have been programming for 20 years. In fact, the ones who have been programming for 20-plus years probably need this book more, as a lot of them have fallen into bad habits or have never even heard of modern programming concepts like object-oriented programming or test-driven development.

If I were to boil this book down to one sentence, it would be: How did we get to the terrible situation where the vast majority of custom code is of poor quality, and what can we (realistically) do to solve this problem?

So the next question is, how did we get here? It is not because the programmers lack skill. Most programs usually start off perfect with no quality issues at all. Then, somehow, they get worse over time as more and more changes and additions are made.

I would say that programs degrade as a result of the false belief that code quality really does not matter at all. I imagine that in 99 percent of organizations, what the programmer is instructed to do is to make the exact change(s) required and ignore the fact that the program is (a) already a horrible mess or (b) your current change will make a fairly good program into more of a mess than it was before. The fact that you are actually making the problem worse over time is neither here nor there, as long as the requirement is met, really quickly.

Most management would say this approach is the only possible way to get things done. Time (and money) is always tight and getting tighter. Therefore, the idea is to make our changes as quickly as possible. In real life, over a protracted period quality code is actually cheaper than poor-quality code because the maintenance effort is so much lower, but that is a very difficult concept to convey.

Fear is always a killerwhen changing a program, if you find an obvious existing bug, do you fix it, even if that is not what you are actually supposed to be doing? In some companies, you could get sacked for that.