Introducing the Concept of Antifragile ABAP

As a general rule, you don’t find too many computer programmers reading books on philosophy. They prefer the binary world of ones and zeros and linear problem solving to abstract musings as to whether anything actually exists.


The only time a programmer even gets remotely interested in anything a philosopher might have to say is when they start speculating that the world we live in is actually a computer simulation. Nonetheless, on the advice of a fellow computer programmer I read the book Antifragile: Things that Gain from Disorder by Nassim Nicholas Taleb which has “philosophy” as its primary tag.


His core argument is that most things in the world are constantly exposed to a series of stressful events or changes, even if the latter is only the passage of time. There are three possible reactions to such stress depending on the nature of whatever it is that gets stressed:

  • If something is fragile then in the best case it stays the same; in the worst case it gets worse (e.g. a wine glass getting dropped).
  • If something is robust then in the best case it stays the same; in the worst case it stays the same (e.g. a “Tonka Toy” getting thrown against the wall by an angry toddler).
  • If something is anti-fragile then in the best case it gets better; in the worst case it stays the same (e.g. a rebellion against a dictator where the more the government cracks down the stronger the movement becomes).

That book had nothing at all to do with programming—the examples all stemmed from economics or biology or politics.


What’s That Got to Do with ABAP?

The horrible, horrible truth is that most existing ABAP programs fall into the fragile basket. Even if a change has been tested rigorously by a dozen people for a month non-stop, that doesn’t stop you from quaking in your boots when the change is moved to production as you, the programmer—and the end users—wait to see what has broken this time.


ABAP Programs Are Like Crocodiles

A program starts life rather like a crocodile egg. You are given a requirement for a read-only list, you code a selection-screen, one database read, and then pass the result to an ALV class to display the data. Very little code, very little that can go wrong, like an egg it just has to sit there and be round.


Then one day you are asked to make a “tiny change” whereby someone can select a line and then press a button and then some action is performed on that data e.g. goods issue a delivery. Oh—and can you make one or two fields editable?


The egg has hatched. Now it is a tiny crocodile, one inch long. It can bite, but it is nothing to worry about. Then comes some more requests: Can you add in some business logic to make some checks before doing the goods issue? Can we have some more buttons for other functions? With each change, the more people start using the program, which leads to more requests for change, which leads to more people using the program and so on.


With every change the following happens to the crocodile:

  • It gets bigger (i.e. more business critical) and its bite becomes more dangerous—what happens if it breaks?
  • It becomes more deformed as it grows (e.g. grows wings, gets a few extra legs); i.e. the program performs more and more functions it was never originally intended to do.
  • It becomes more fragile with every change. That is, the first change has a 1% chance of breaking something, the second has a 2% chance, the third has a 4% chance, the fourth has an 8% chance, and so on until the chance of something breaking with every change reaches 100%.

You end up with a 50-foot-long crocodile made of glass with seven heads and twenty-three legs and if the slightest thing goes wrong with it then the business takes a million-dollar loss. At that point you are stuck—you really don’t want to make any changes at all (it is far too dangerous) and yet the amount of change requests does not decrease; if anything, they increase over time.


In other words, the entire code base rots over time until the whole system is a big ball of stinking mud which by some miracle keeps working but is skating on ever thinner ice.


It Doesn’t Have to Be This Way

You might be thinking: “That’s nonsense! My system is not like that, even if we do have a lot of unexpected failures every time something goes to production!” And, people in some companies would be thinking “That’s nonsense! We never have any unexpected failures—ever. We haven’t had one in ten years!”


Obviously some companies have managed to overcome this problem. The example I love to quote is Amazon, which puts a change into its productive system on average once every 0.59 seconds and has no trouble whatsoever.


So if you don’t have this problem: wonderful. But if you do find yourself in this boat—the “I can’t be 100% sure nothing will break when this goes into production” boat—then there are steps you can take to address the problem.


Recommendation: Antifragile ABAP

If your program has reached a state of extreme fragility, then write all new code somewhere else (this could be a function module but preferably one or more classes) which the existing code then calls. If you are changing code, move that code to the new place. This is the “open/closed” principle—you are extending what the existing program can do without modifying that core program. If you think about it, that is what user exits do. There is no law that says you can’t have user exits in your own Z programs.


Write that new code in an object-oriented (OO) fashion. A lot of ABAP programmers would crawl over a thousand miles of broken glass rather than having to write a method as opposed to a FORM routine, but even if there were no positive points to switching to OO programming (and there are loads) then at the very least it enables the next point.


Write your new code in a “test-driven development” manner using ABAP Unit. That way you start to have automated regression tests, so that in the future you know when one change to an area breaks something seemingly unrelated. The more changes you make, the more tests you have and so the less fragile the program becomes. The program will become antifragile.


Always run the extended syntax check and code inspector. A lot of people treat these as a waste of time, but all those warnings and errors thrown up by those tools are not just there for fun—they actually indicate problems which can sometimes turn out to be fatal.



A lot of existing code is fragile in that not only is it likely to break with every change, but even worse, each change made increases the probability of something breaking when the next change comes along. A vicious circle.


However, it is possible to reverse this cycle and move to the situation where the program is antifragile—the more changes you make the less likely the program is to break when changed in the future.


This is not just an academic theory. I have done this in real life.


As a result, I wrote an E-Bite describing the step-by-step process I used to transform a horrible glass crocodile of a program which ran away from change requests, into a tungsten crocodile which eats change requests for breakfast.


If that has piqued your curiosity then you may be interested in reading Refactoring Legacy ABAP Code. You can also use the coupon code RLAC10 to receive a 10% discount on the E-Bite on the SAP PRESS website.


Refactoring Legacy ABAP Code
Refactoring Legacy ABAP Code

Legacy code. All developers, even ABAPers, have to deal with it—but how? Enter this E-Bite! First up, you’ll get a thorough grounding in the theory behind refactoring legacy procedural code into object-oriented code and how it relates to ABAP. Then, the actual work begins! Step-by-step instructions will lead you through isolating code, breaking dependencies, ensuring new and old code “talk” to each other properly, and more. It’s time to step up your code maintenance game!

Learn More
Paul Hardy
by Paul Hardy

Paul Hardy is a senior ABAP developer at Hanson and has worked on SAP rollouts at multiple companies all over the world.