Programming by permutation

Trying to approach a solution to a programming problem by iteratively making small changes (permutations) and testing each change to see if it behaves as expected is called "programming by permutation". This approach sometimes seems attractive when the programmer does not fully understand the code, and believes that one or more small modifications may result in code that is correct.

This tactic is rarely productive because:
* a series of small modifications can easily introduce bugs into the code, leading to a "solution" that is even less correct than the starting point
* many false starts and corrections usually occur before a satisfactory endpoint is reached
* it is rarely possible to measure, by empirical testing, whether the solution will work for all cases
* in the worst case, with poor code management, the original state of the code may be irretrievably lost

Programming by permutation gives little or no assurance about the quality of the code produced -- it is the polar opposite of Formal verification.

Programmers are often compelled to program by permutation when an API is insufficiently documented. This lack of clarity drives others to copy and paste from reference code which is assumed to be correct, but was itself written as a result of programming by permutation.

In some cases where the programmer can logically explain that exactly one out of a small set of variations must work programming by permutation leads to correct code (which then can be verified) and makes it unnecessary to think about the other (wrong) variations.

Example

For example, the following code sample in C (intended to find and copy a series of digits from a larger string) has several problems:

char* buffer = "123abc";char destination [10] ; int i = 0;int j = 0;int l = strlen(buffer);

while (i < l){ if (isdigit(buffer [i] )) destination [j++] = buffer [i++] ; i++;}

destination [j] = '