A Hard Truth
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.
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.
posted by Anonymous at 7/24/2007 09:51:00 AM
2 Comments:
Another important reason to discuss performance expectations early is because they can have a big impact on the architecture selected. It can be difficult and expensive to rearchitect a system to correct severely deficient performance problems, whereas knowing about stringent performance requirements up front can lead to design choices to satisfy them. Planguage is a good technique for specifying performance and other quality requirements in a precise but flexible way to include shades of gray: "must" goal, nominal target, and ideal outcome.
This post is being discussed here:
http://www.seilevel.com/messageboard/showthread.php?t=619
Post a Comment
<< Home