ABAP_to_the_Future

Debugging is twice as hard as writing the code in the first place. Therefore,
if you write the code as cleverly as possible, you are, by definition, not
smart enough to debug it.
—Brian W. Kernighan and P. J. Plauger, The Elements of Programming Style
5 Debugger Scripting
Most of us hate bugs, be they the ones in our programs or the ones with 500 legs
and two bright red pincers, those that crawl up our legs when we’re not looking.
Therefore, in previous chapters you’ve seen how you can do dynamic tests as an
integral part of writing programs wi th test-driven development and how the
ABAP Test Cockpit helps with static chec ks on your code. These elements represent
a two-pronged attack on bugs that tries to kill them before they have taken
root.
However, bugs are always with us; a program almost never does everything that
was desired with no errors the very first time it is run in Development or QA.
(This despite Robert C. Martin’s insistence in The Clean Coder that “QA should find
nothing.”) You should always expect the first few tests—by yourself or others—to
return unexpected results.
If someone else tells you that the mons ter simulator program is producing blue
monsters with two heads when you were expecting green monsters with three
heads, then you need to identify the so urce of the problem. If you’ve ever done
this—and I suspect you have—then you know that there are days when you
spend four hours looking for the problem, and once it finally rears its ugly head
the solution is so obvious that you can make the code change to fix up whatever
it is in about two minutes flat.
The problem at hand is that you sit in front of a debugger looking for the same
sort of thing in different programs, ag ain and again, month after month, year
after year, when you would rather spend that time writing programs. What if you
could solve this problem by doing exactly that—writing programs—thus turning
something really boring into something really fun and solving your employer’s
203