I imagined some people would crop up with experience at RHIC/CERN. I never touched the SixTrack code directly but I've heard legend. The compile time features w

I imagined some people would crop up with experience at RHIC/CERN. I never touched the SixTrack code directly but I've heard legend. The compile time features was a constant on all the projects I touched there and was such a hilarious relic. "The code is flexible! Just know these completely undocumented flags or spend months grokking the dense/obtuse/scattered source files and you can make the code do anything you want, all these hard coded constants will change". As ugly as things like SixTrack were, I vaguely trust them just because there were usually a lot of eyes on them... even if they were hideous. The more obscure chunks of code that were somewhere in the analysis chain were the ones that really terrified me. I worked on a lot of the code for simulating detector upgrades (I won't get more specific than that) and that was a terrifying place. Designing entire multi-billion dollar detectors systems based on hundreds of different pieces of code and output data that were glued together with no over-arching design or integration. The code 'review' usually came down to "that output looks good"... or not... Related to this, I now work in the atmospheric sciences, and a completely-unrelated-but-oddly-similar problem exists in the various modeling communities. So many fragmented pieces of code glued together and untouched or touched with no real computing oversight. So many wasted computing cycles. So many failure points.