A business owner and I were prioritizing requirements for a product release. Among them were the performance requirements. He did not want to give them high priority, fearing untold hours would be spent on performance. He needs a breadth of the features delivered. My fear was that no consideration would be given to performance if we didn’t prioritize it.
After sleeping on it, I was able to express my position in better terms. I agreed that at this point in our project, tweaking performance is not a priority. If we want 3 second responses but are getting 5 second responses, we can live with that for now; other features are definitely more important.
However, if performance is so poor as to render a feature unusable (5 minutes instead of 3 seconds), then the hard truth is that we have not received the feature. It may have a beautiful user interface. It may produce 100% accurate results. But, if it cannot produce them in an acceptable time, then we didn’t get the feature. We need to include the performance requirements to make it clear we consider them part of the feature.
Stated in these terms, the business owner agreed. But, concerned, asked “What if the development team needs a month just to provide barley adequate performance?” My response which received a nod of agreement “Don’t you need to know that?”
It’s a hard truth that we don’t like to face. Sometimes there are simply minimum standards of acceptability, and we need to state them. And, be willing to pay for them.
