This story I think very neatly points out the difference between verification and validation -- and why it's important to have both of them in a testplan for anything new.

In short, verification asks the question: "does it do what we designed it to do?" For instance, if you have a reference encoder of some kind that is a verbatim translation of a specification, and a high-performance encoder that is designed to squeeze every last drop out of the system, you can verify the high-performance version by comparing the output to the reference; if they're the same, then you know that the high-performance version, at least on some level, works as designed.

If verification compares the design against the implementation, then validation asks the question: "is the design what it needs to be?". The story that xiphmont told here is a validation issue: the implementation is perfectly correct, but it's the design that isn't what he'd hoped for! Although verification often takes more of the time than validation, in my experience, validation often seems to take quite a lot more creativity than verification.

Thanks to Monty for writing this up, and providing such an illustrative example of the difference! It's a useful distinction to have, especially when looking at errors that escaped testing and made it to production.