Seems like a rhetorical question and perhaps it is for the majority. Yet even the obviousness can be skipped for simply the fact that we assumed too much. A good example is the work invested in updating the Deriven FTPSecurity application for the past month.
The application works for up to Windows 2003 and possibly Windows 2008, but not Windows 2008 R2. Therefore it wasn’t going to be added to the new web site, though the download link to the previous version remains intact. A user by the name of Greg had a request to add a new feature to the applicaton while keeping the integrity of the last version published. The new feature was a no-brainer as far as development stood. But testing required a machine with Windows XP, Windows 2003, or one of the premium editions of Vista or 7. Well no test machine was available. Instead and thankfully so, instrumentation was placed all throughout the application to locate any bugs.
Indeed the trace logs showed the bug clear as a sunny day. But I couldn’t see it. The code was reviewed for nearly a month with back and forth testing by Greg and his team. Finally the bug was found by the same trace logs only that by running the code through my head did I see the problem. Had a testing environment been set up (mind you, even the development machine could not test this application since it was not a premium edition), the answer and perhaps even more features could’ve been created in the same amount of time it took to get the desired feature implemented.
Moral here is: how important are testing environments? Even when you are absolutely certain nothing can go wrong? In development, doubt can save time.
