Requirements...
Posted on February 6, 2008
by Tommy McGuire
Shortly after I moved to the Huntsville area, I had an interview with some nice folks from Colsa at the Software Engineering Directorate on Redstone Arsenal. They were looking for someone to work on the new Systems Test and Integration Laboratory. (That STIL link is completely unrelated to the SED or Redstone, but is the best description of the project that I have found.)During the interview, I was asked a couple of variations of the question, "What would you do if you were given a set of totally evil requirements?" I babbled a bit, thought about it a somewhat too long for them, and the best reply I could come up with involved the word "prototypes".
Thinking about the interview later, I had serious trouble trying to decide why I had such a difficult time with the question. What finally came to me was that I had never been given a set of requirements! In my entire career, since I graduated the first time, I have never been on a project that involved a set of requirements handed down from above!
Sure, I have worked on projects that had requirements documents, such as the IBM WorkplaceOS project (such as it was), but that was ages ago, and my portion of the project was to write benchmarks to exercise the system; there were no written requirements for my part of the project. (Had there been, it seems likely that the framework I was basing on would not have had some of the monumental bugs that it did. Like the parameter that was supposed to represent an error percentage with a default of 10% but actually was just used as a divisor; the default of 10 works since x/10 == 10% of x, but no other value would....)
This seems to be a significant difference between Huntsville and Austin. In almost all of my previous (and current) jobs, I was expected to figure out the requirements myself. At best, I was given an initial problem definition ("This server soaks up too much memory. Fix it.") or some other prototypical system or reference implementation. And the best (and only reliable) way I have found to weasel out requirements is to give the customer something they can play with, so that they can provide me with complaints. Just asking the customer for requirements beforehand would be like asking a bobble-head; a magic 8-ball would be an improvement.
Anyway, I did not get the job. I was very disappointed. The work they are doing in the STIL is seriously cool.
