In keeping with the design principles espoused at the beginning of this document, the somewhat controversial decision was made to have no postcode validation. The objections were immediate and obvious "But surely it’s a good idea to validate the postcode before processed?" Well, yes it was, but it didn’t have to be a good idea, it had to be a necessary idea. Consider the following questions:-
The question of postcode validity is not trivial: for example is "90210" a valid postcode? It is if you’re in California, but not if you’re in Grimsby (and perhaps the Grimsby person does actually want to go to California). A postcode can only be validated if the location and intent of the enquirer is known. It was possible to install software to deduce this or for the user to input it, but this was a clear violation of the second design principle: simple is better than good.
If you stop an invalid postcode, then software would have to be installed to validate a postcode, error messages would have to be created to indicate to the user that an error has taken place, new screens would have to be displayed, and the point was clear: this was another violation of the second design principle.
The third question proved to be the vital one. If an invalid postcode was let through, then the system would assign it a default node and plot a course from that node, and it would be obvious to the user that a mistake had been made. In short the system would work fine without any validation, so validation would be a violation of the sixth design principle: if you don’t have to do it, don’t do it.
Postcode validation was omitted from this thesis.