How does the code, by itself, describe the business needs that that section of code is supposed to fulfill? How does the maintenance programmer tell if those business needs have changed?

How do I use a programming language, in and of itself, to signal that a given, efficient but obscure algorithm is correct, and that the "obvious solution" is not the right one?

As a real world example, one of my friends worked on an open source game. He was repeatedly annoyed by people trying to "simplify" a complex section of code, by consistantly making simplifying assumptions that initially appeared correct, but simply weren't true for all cases.

How did he fix the code? He put in three formal proofs of algorithm correctness, documented the underlying assumptions that the would-be optimizers consistantly missed; and carefully listed all the criteria that a refactored solution would require in order to be complete.

People stopped breaking the code after that; because there was enough information in the comments to force them to realize what the code actually did, and why it needed to be written the way it was...