Well, I'm totally in favour of Ms Smith's views, except perhaps where she writes "Explicitly dealing with failure" in her list of problems where she clearly means "Not explicitly dealing with failure". I've written the odd diatribe on that topic (which has included suggesting that those who simultaneously fail to deal with failure while logging too much irrelevant junk and logging no useful diagnostics, so that they fail on all Ms Smith's first three bullet points - which for me are just essential parts of error management - should be locked up and not be permitted to develop anything or manage anything. Unfortuantely the concensus amongst holders of degrees in IT and of MBAs seems to be that anyone who wants error management should be locked up and shunned :angry:, so I used to spend a lot of time being rather grumpy.

I think your editorial watered it down rather a lot, and this passage is why I rated it only 3 stars (otherwise I would probably have rated int 5 starts for raising such an important - and controversial- topic:

A couple of months is nowhere near enough for the users to develop power users who will be pushing the product to its limits and discovering the bugs that are hard to fix. I suspect you are making the same mistake as one of the commenters on the original post, and treating the "you" in "you write it, you support it" as refering to an individual instead of to the development team as a whole, because I can't imagine any reason for limiting this support to a couple of months other than that the person who wrote the code may no longer be available.

Of course there has to be a proper understanding of which parts of support are a development responsability: holding the users hand, making sure that he remembers to plug the power lead in, and so on isn't a development responsability (it's actually the responsability of the user's manager). Neither is what I call "first line support" (usually fixing the user's failure to RTFM, and rarely explaining errors in TFM). But second line support - helping the user to model what the product does when the manual fails to deliver the required information - and third line support - fixing the errors and omissions in the product - should always be considered a development responsability.

I worked full time in software and database R&D for more than 40 years (that's excluding time as a research student) and was a recruiting manager for most of that time (about 30 years, not all at the end of those 40+). Very early on I adopted a policy of not recruiting people for anything other than very junior/new graduate posts who didn't have real experience of customer support, because people without that experience tended not to be particularly careful about making sure their stuff worked in all imaginable circumstances (of course no-one succedes in doing that all the time, but people without customer support experience tend not even to try hard). Developers who think they have more important things to do than make their product work for the customers are, IMHO, a waste of space, and development teams who have that collective ethic even more so.