In a LinkedIn Delphi group a provocative question "Is the vast majority of Delphi code in most organizations spaghetti?" has generated a rather interesting thread.

The original question (by James) was: "Being a newbie, it seems as if Object-Oriented constructs didn't exist until very late in the maturity of Delphi. Does this make Delphi code harder to maintain for "new" developers than other languages?"

One of the first few answers (by Kirk) was up to the point: "Delphi was always object oriented. Any component architecture is, by definition, OO. This doesn't make it impossible to write bad code, and spaghetti is only one flavor of many possible bad code, but TObject was always the single ancestor object and interfaces, introduced in version 3 were added specifically to avoid multiple inheritance and all the problems which that entails. "

My two comment follow: 

Marco Cantu' •  "Delphi let's you use a pure OOP coding style or a visual/RAD coding  style. The latter can certainly drive towards spaghetti code. But you have options. The best option is to merge the two, use RAD for what it is worth, but without breaking OOP rules, write custom components (OOP), organize your class structures, add business and persistence layers, and much more. Used badly, it is not a good tool!"

Marco Cantu' • As for the original question, many organizations have Delphi code 
without a good architecture, but all of the larger projects generally are quite good. 
I'd say 30% might need a rather complete rewrite!