Very true. A friend of mine, who worked for a very large company at the time, once described the perfect system for achieving recognition as a developer. Firstly, write code that's full of bugs and is hard to maintain. Secondly, once the code is shipped and starts going wrong, make sure you step up to the plate and fix all the bugs that you created. That way, you get kudos for delivering code rapidly and for all the customer support work you do. Contrast that with the guy who writes good quality code who doesn't ship as rapidly and who doesn't have half as much customer contact.
I don't have the citation on hand, but this goes along with a study I read about customer loyalty. Customers who have a problem which is promptly corrected by the company are more loyal than customers that never have any problems.
I think that makes a lot of sense - relationships build loyalty and trust (as long as they are positive in nature). Buying something and never interacting with the producer doesn't build much of a relationship - it's merely a transaction.
I think there's an awful lot of truth in that. You could make the argument that customers of Enterprise Software (that we love to deride) are not paying for the awesome quality of the software so much as for the assurance that the company will pull out all the stops to support them if anything does go wrong with the software. On a psychological level, that leads to a good relationship. On a practical level, that means that the customer is paying not for a great experience when things are going well but for a good experience when things go wrong.
