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 worked—they 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 extent—but only to an extent.

What is meant by the code’s being “no good” is that the analyzed programs were “big balls of mud”—prone 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.