Tom Ramcigam (magicmarmot) wrote,
Tom Ramcigam
magicmarmot

Code geek rant

I had an epiphany yesterday.

Some background: part of what the software that I'm working with does is data collection, and we had a bug that showed up during a manufacturing test that I eventually traced back to the working of a feature that had been specifically requested. It turned out that with extremely long scan times, the system would lock up when something went wrong that would trigger this particular feature.

The issue appeared because nobody had ever really considered the ramifications of long scan times in the operation of this feature, and while it could be argued that it was something that should have been thought of in the requirements phase, the fact is that it wasn't, and extrapolating that into the larger picture, it hit me:

Given a system of sufficient complexity, it is impossible to fully define all of the software requirements.

While philosophically this is a nifty thing, the practical implication is that there needs to be some sort of mechanism in the software process to catch exceptions later in the process. This also has broader implications for things like scheduling accuracy, as a requirement exception should be treated as a new requirement for the purposes of planning.
Tags: codegeek, work
Subscribe
  • Post a new comment

    Error

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 1 comment