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.