djackson 22568 (12/8/2011)
cfradenburg (12/8/2011)
I'm not sure that a resource issue with the development process is a good justification for delaying security patches. I do understand that other items need to be in the queue but if a companies method of prioritization is such that the number of known security issues grows while other features are getting coding then they have an issue with prioritization. If it ain't broke, don't fix it. However, if it's broke and you're finding it's more broke stop building on it until it's fixed.In my experience with absolutely every software company I have been involved with, either as a worker or customer, the focus is on new sales. This ends up meaning that a bug fix is not prioritized, because sales and marketing are looking for that cool new feature to market, or that part of the product that meets some government regulation, or anything like that.
Fixing a bug is not cool, nor marketable, and sales and marketing are almost never going to push for that over what they view as pushing new sales.
Whether they are correct or not is irrelevant, but it is how they think.
Dave
Not so, in my experience. You have to factor in the cost of support, which goes up if the product is buggy. Sales want their features today, but top management has to see the whole picture and make a balanced decision, and it is the top management that gives a go to the new release.
That said, I do know that there are "smart" managers who release a product with known serious bugs on assumption that before the customer installs it, there will be a fix available on the Web. Sometimes it works, often it does not.