Feature requests are a bit like onions. They make you cry, and they have layers.

Dig a little deeper than the surface of an ordinary-looking feature request, and you can often find a whole set of business practices that you didn't know about.

Case in point: We have a farm who has started receiving pregnant sows from another farm. Let's say they were mated at farm 'A' and then transferred over to farm 'B'.

Senior management came to ask asking that all the matings on farm 'A' be changed in the database so that they appeared to have happened on farm 'B'. It seemed odd to us that a manager with so much experience would be asking that data be changed so that it is less accurate, so we probed a little further.

What he really wanted was a way for farm 'B' to find out how many animals currently on their farm were mated back on farm 'A' in a given week. We explained that it was a simple, half-hour job to write a report that could give them these figures, rather than altering the data. Thankfully he acquiesced.

Now, let me pause right here and say: Why can't managers have a bit of foresight? Didn't he realise that one day he might have actually wanted to know how many animals were mated on farm 'A'? If we had blindly followed his instructions, those figures would be lost forever.

Anyway, the story continues . . .

Julie creates the new report and contacts the manager of farm 'B' to demonstrate it. We haven't talked to this guy yet, because the initial instructions were from his boss. He looks at the report, and likes what he sees. That's a win for us.

However.

Julie probes even further, and discovers that the real reason the manager of farm 'B' wants this report is so he can tell how many animals came from farm 'A' to his site! It has nothing to do with matings! In fact, there's already an 'Animals Transferred into your Farm' report that he could have used! Once we pointed that report out to him, he agreed that the new report was no longer necessary. We were able to set up a subscription in SQL Server Reporting Services so that the 'transfers in' report is emailed to Farm 'B' every day.

So there's a couple of wasted hours, all because the original feature request was based on a false premise. I guess there are two morals to this story:

  1. Never implement a feature request without knowing the real reason behind it, and
  2. Always ask the guy down in the trenches rather than relying on the word of senior management.