Specifications and Assumptions

We all know what it means to assume — but sometimes our assumptions are so completely hidden from us that we don’t even know when we are assuming.

I had an iinteresting conversation with another developer last week that illustrates this point (…and a few others that I’ve blogged about also).  It seems that my developer friend had been involved in a project for another developer who had created an apparently extensive (read as complete) almost 80 page specification regarding what the application was to accomplish, and how.  Required tables and fields had been defined, as had been the associated indexs for the tables.  (Personally, by the time I would have developed such a document I could have had a significant portion of the program created - but that is another story!). 

In the development process all appeared to be proceeding as desired — and then the customer began testing.  It seems that with one of the tables the documented indexes reflected a configuration which would allow duplicate child records - not what was desired - but what the spec allowed.  An assumption was made on the part of the developer writing the code that since the index allowed for duplicates, then duplicates must be desired and programmed to allow them (…all the while knowing that it was not usual).

This one instance indicates a problem that all developers face.  In my experience, it seems that no matter how detailed the spec, there always seems to be some underlying assumptions being made - and they make for keeping our jobs interesting.