I once worked at a company that got rid of it’s sustaining engineering. For the same reason as the chart stated… sustaining software costs a lot of money. If you are taking in revenue from a product, having customers stay on old products costs the company a bit of revenue in which they can get from having the customer upgrade. I know a great number of people who have said at one time or another, this works great for me, why should I upgrade?
Even if you are not taking revenue from the product, there still lies an underlying cost of taking engineers time out to make a fix, qualify the fix and then releasing the fix in some fashion, then marketing/advertising the fix out. (And even if you aren’t taking revenue from the product, the question still lingers, “Why should I upgrade?”)
To me, QA is about prevention. You can save money and time by preventing issues from occurring in the first place before the end user sees the issue. It’s proactive work versus reactive. Some of it’s simple work. Such as keeping track of the most commonly forgotten things in development, such as internationalization things (double byte characters, RTL), to knowing what’s going on in one project that’s related and making sure the communication is there and the item is accounted for. To understand circumstances, such as when a pointer is null or could be null (examples, new profile creation, deletions, additions). Locking issues such as with a file, or a resource… performance such as using the big o notation to calculate how fast a loop might go… not placing in variables within a loop. Just mentioning it as an innocent question could help remind developers before they even create a bug on it.
Filed under: Uncategorized 
