Although formal problem solving techniques, such as those used in the programming languages SPARK or Ada, have not yet found widespread usage (Glenn Brookshear, J. (2009)) most algorithm developers use informal problem solving techniques, usually concerning the use of test data and considering expected results and adjusting the algorithm as necessary and re-testing. From experience (similar to Polya’s phases), this informal procedure should contain the following steps:
- Analyse the problem (understand, use the success of other similar problems solved (Helmholtz / Poincaré)), consider the objective, the variables, the logic and legal input)
- Design the algorithm (pseudo code, documented for later review and if the problem has an algorithmic solution?)
- Implement the algorithm in code (translate the pseudo code into relevant programming language)
- Verify that the algorithm works (introduce relevant test data that is representative of the data expected by the algorithm and test the limitations for legal input if necessary)
- Monitor the success of the algorithm and restart the process if necessary
When overseeing the implementation of a new algorithm into an academic certificate processing we were required to simplify the sending out of certificates to students to reduce mailing costs. The university in question was sending out a certificate for each module passed for courses and students could take multiple modules when they could fit up to four certificates into a single mailing for the same cost. The university decided to task their own IT department with introducing the new algorithm and changing the code; ultimately the responsibility was given to one, not untalented, programmer.
The programmer took a sample of the data and wrote an algorithm which read the certificate run data, sorted the list by student name, counted how many names were identical and performed the concatenation accurately of up to 4 certificate references into one record and removed the three concatenated records, then output the new list for the certificate run.
The programmer’s logic seems to work and the new algorithm was put into practice however it quickly became apparent that student’s were not receiving certificates due one small error in the algorithm; there was no way to check from the source data whether names were actually for the same student or two or more students with coincidentally the same name. Needless to say this was rectified by the consideration of a unique student number (however this entailed database and program changes), however the problem here was that the programmer had not followed a structured problem solving process that took into account whether the output of the system was valid (as opposed to logical)
The greatest issue with this informal technique is that algorithm success is often judged without the consideration that an algorithm should be correct, unambiguous, precise and efficient and often only the ‘correct’ characteristic is tested. This leads to many algorithms not quite being what they should be in the real world and supports the argument for a formal problem solving procedure.