In computer programming, Unintentional Programming (UP) is a programming paradigm inspired by the old adages, “Even a stopped clock gives the right time twice a day” and “If it ain’t broke, don’t fix it.” It is a method for writing source code that happens to produce apparently-correct results upon cursory inspection, but without arriving at those results through any intentional, correct, sensible, or predictable internal operation. By not thinking through all possible states, adding non-obvious dependencies on untested assumptions, not stepping through program execution, and creating needlessly convoluted workarounds to simple problems, the programmer greatly increases the probability their program will accidentally produce superficially correct results for at least some contexts.
Because software developed using Unintentional Programming arrives at correct results through sequences, states, and inputs never imagined or intended by the programmer, such software is incredibly difficult to maintain or improve. The extreme disconnect between internal program operation and external results means that any change made to the source code can produce disastrously unexpected results. Identifying why the program happens to produce correct results in some cases is just as difficult as identifying why it happens to produce incorrect results in other cases. The conditions and sequence of operations that lead the program to produce incorrect results are so convoluted and difficult for the human mind to comprehend that the program’s behavior is, for all practical purposes, non-deterministic.
Due to its unpredictability, source code developed via Unintentional Programming can be frustrating for all members of an engineering team to work with. For example, any attempt to replace some portion of the source code with new code that intentionally arrives at correct results will inevitably result in “breaking” cases that happened to produce correct results for the wrong reasons before the change, but which now produce incorrect results for the right reasons, frustrating everyone who thought it was working just fine before the change, naturally motivating them to fault the programmer who made the change rather than the unintentional nature of the old code. Developers tasked with gradually transforming an existing large body of UP source code into software that behaves intentionally, sensibly, predictably, and correctly, face higher rates of nervous breakdown and ulcerative colitis than do their peers stranded inside underground bunkers on eerily magnetic tropical islands following airplane crashes.