My boss, the wise man that he is, realizes that since I was the one building the software – that I might be able to stare at it for hours and not see a thing wrong with it.
This lead to a discussion on the root of the issue, a failure of process.
I take the blame for my small failure to notice a missing file, but in reality if our process were complete – there would be no way for me to miss it. This point was the subject of an entire semester’s schooling at Trent University‘s Computer Science program.
The gist of it is this. Each project requires a document stating a list of requirements. This list of requirements shall state concisely and clearly each and every operation the project is to perform.
A ‘requirement’ must be testable to be considered a requirement and it should be stated with a ‘shall’ to make it completely unambiguous.
Afterward, all that is required of the developer of a project is to implement only those features that satisfy the list of requirements. If it is not written in the requirements document, it should not be in the project. If the project won’t work without some feature not included in the requirements document, the requirements document needs to be re-written.
If you finally get to a stage where you can test the project, testing is easy! The requirements document becomes a checklist. A developer, preferably someone who wasn’t coding the project in the first place but who understands its logic, shall read through the list of requirements one by one, checking off all which are fully met.
That’s it! It’s a lot of work, really… but when you consider that it really only takes a few extra minutes of your time and that mistakes in an industry such as information technology can be extremely costly (programming mistakes can even cost lives!), you should use proper processes to develop your software. There shouldn’t be any question about it. You need to spend the time on proper process. Otherwise you’re bound to make costly mistakes, sooner or later. Let’s hope it’s sooner.