A public face

This past week brought quite a few MVPs by our offices. Per usual, it was nice to be able to show a very little of what we're doing. On the other hand, it introduces another level of information dispersal and access protection to think about. On the one hand, acknowledging a problem with the software or talking about a planned feature could be considered to be an implicit promise to fix or implement something. On the other hand, not talking about what we're doing means that we miss out on valuable feedback.

So what would have been future design feedback is now feedback on existing design, which is, well, not always pleasant. It is sometimes difficult to participate on public newsgroups or mailing lists. One doesn't read much positive feedback (but then again would you really join a newsgroup to laud the developers who wrote the feature that made your day?), and there's as much negative feedback as one might want. Some of it is completely appropriate, and takes you back several months to the point where there was an agonizing choice... either the PMs at an adds/cuts meeting, or at some late point when a problem was finally realized where all the principals weigh the cost of addressing it and making sure that it was really fixed without other repercussions. I wince once when a hard decision happens, and then again when that first person says, "What were you thinking when you wrote that?" or "Don't you do any testing?"

It's just not useful, for me at least, to try and address all the posts. Some are unrelated to the software at all, and have to get redirected to a more appropriate area. Others are FAQs, asked on the order of three to four times a week, and points to people's lack of willingness to search the archives. Some, though, are the good problems: the ones we don't see in-house, the environments we don't have in a test lab or on a dogfooder's or beta tester's computer. These are the ones where one tenacious and helpful user makes it so we can fix the problem for untold others who won't report the issue. The other good ones are when there is an obscure error message that doesn't have an obvious solution but that we can help diagnose what's going on and solve some settings issue or help out with some workaround. Being able to respond to those makes me feel good about my work.

Then there are the total flame bombs that get dropped by irate customers, or better yet, irate non-customers. I personally do not know how to respond in a positive fashion to these, especially the ones that have horribly flawed or missing logic. I really don't understand the sense of entitlement evidenced by some posts. That a piece of software might not do everything you want should be par for the course, but does it mean that you're somehow entitled to have it "fixed" to do what you want it to do? Is it merely a problem of that the public listing of features not being specific enough to let you know what will and will not work? Comparing one piece of software to another might be useful to pick which piece of software is appropriate to use, but if it compares unfavorably, does it really mean that you're due some kind of replacement version that addresses those problems?

Ultimately, I will go into work and write the best software I can.