Monthly Archives: April 2005

Imperfect Feedback Loops

In one of the comments on my Community Can Be Cruel entry, Karl said:

One of the problems with custom engagement in the forms of these blogs is that it makes the customer believe he or she might be able provide input which will ultimately have an effect on decisions taken. While this may be true in some cases, it certainly isn’t in others. This isn’t anything wrong on your part, and I certainly don’t want you to stop, it’s just hard sometimes for the community to accept that decisions have been made and that our arguments via feedback are, at best, good theoretical debates.

I think Karl’s right that people end up feeling this way, and it’s something that is partially unavoidable and partially due to the way this product cycle has run. On the unavoidable side of things, there’s no getting around the reality that when a complete consensus cannot be reached someone ultimately has to make the decision. To take the example of the default instances debate, we really did listen to all the comments that people made concerning the feature and discussed them seriously. And, belying our Borg reputation, there was a lively debate internally about the feature, with people on all sides of the issue. This included people who, I should say, voiced many of the same concerns and objections that community members did. In the end, though, a decision had to be made and one choice among the many chosen. I know that when a choice is made that doesn’t agree with your opinions, and especially when those opinions are shared among others in your particular network, it can seem very much like your opinion wasn’t listened to or valued even if was taken into full consideration. We do our best to try and let people know that we listened and be up front about our reasons for taking a different course, but some difficult feelings are probably inevitable.

That aside, though, I think that there has been an extra level of angst about feedback this time around due to factors that aren’t inherent in the development process. The nature of things is that many product design decisions are made well before a beta ever ships. While we always can and do make changes based on beta feedback, the truth is that some decisions are hard to change unless they are caught very early because of the size or the risk the change would entail. Similarly, by the time that a beta is out most of the new feature development time has been used up, so feedback on priorities (i.e. “I want feature x more than I want feature y.”) can be difficult to react to, especially if the features requiring significant development investment.

The problem with the Whidbey cycle is that many of the community engagements that we’re now using to gather feedback (forums, blogs, MSDN Product Feedback Center) didn’t come online until later in the product cycle. I believe the product feedback center came online during Beta1. The forums are coming online in Beta2. Even this blog didn’t really get going until the winter of 2003/spring of 2004. What this means is that a lot of the feedback mechanisms that many of you are participating in now didn’t exist early on in the product cycle when many of the critical decisions were being made. This isn’t to say that there was no feedback – we have lots of traditional feedback channels that were being consulted throughout the cycle – just that many of the communities that are now plugged directly into the feedback loop weren’t there. That’s the bad news. The good news, of course, is that as we approach the dénouement of this release and start gearing up to look beyond, you’re all going to be right there from the beginning.

And, finally, there have been some interesting rumblings from my management chain about moving towards an even more transparent development process in the future. How this will play out is unclear to me, but I think there may be some interesting experiments in community engagement coming…

Refactoring: For VB 2005!

As someone very wise once said, the problem with making confident predictions about the future is that time has a way of making a liar out of you despite your best intentions. The good news in this case, in case you haven’t heard it elsewhere, is that VB 2005 will have refactoring features! Both Brad and Cory have some good discussion on this and you can check out the official announcement on MSDN. Personally, I think this is just great and kudos to the VB folks and the Developer Express folks who made this happen.

I will also observe that the old debate appears to be settled for the moment, at least…

Community Can Be Cruel (or, If You Prick Us Do We Not Bleed?)

Something Josh Ledgard said struck me as he was talking about an angry email he got about the introduction of the new web-based MSDN Forums:

I’ve heard Scoble say it a lot… if you work at Microsoft… and you blog… you had better have think [sic] skin. My own experience suggests that having an active blog at Microsoft for any length of time pretty much guarantees you your share of mails like this and it does effect [sic] you… at least it effects [sic] me. Not to get too touchy-feely, but I’m not some Borg drone that doesn’t ever feel insulted. None of the MS Bloggers I’ve met are either. If you send us mail it ends up on the screen of a real person for better or worse. Please think about that before you press send. I’m not saying I’ve never offended anyone with my blog, IM, or e-mail but…

When I posted my latest entry on default instances (and I know I still need to respond to several of the comments left there), one of my coworkers sent me an email saying, more or less, “Ah, I see you’re the poor bastard who was elected to take the brunt of this.” By and large, though, I don’t have much of an issue with the responses that I got – as Josh/Scoble says, you have to have a pretty thick skin (or develop one really quickly) if you’re going to do anything that involves interacting with the community. Some people were definitely upset, but pretty much everyone was pretty reasonable about the whole thing.

But I think that sometimes there really is a dark side to customer engagement. While it’s easy to talk about how great it is to engage with the community, such engagement always comes at a human cost. Because ultimately one of the major features of the producer/consumer relationship is the power struggle that goes on between the two sides of the equation. The producers have generally free rein as to what they want to produce, but are dependent on the consumer to fork over their money for it. The consumers are free to spend their money however they like, but once they’ve bought into a particular product, they are dependent on the producer to give them what they want. Any relationship like this is bound to produce its fair share of unhappiness and anger at times for both parties. The problem is, where does that anger or unhappiness go?

As producers, we’re pretty much prohibited from taking out our anger or unhappiness on the consumer. Oh, sure, it happens, sometimes in a subtle or passive-aggressive way, but generally producers who treat their customers with disrespect like that are going to have a hard time finding customers. On the other hand, the consumer is pretty much free to vent their displeasure at the producer however they see fit because they know, generally, that the producer cannot return fire. This means that consumers are often free to treat producers (who are, after all, still human beings) with all manner of disrespect and contempt, safe in the knowledge that they will never be called on their behavior. Rare is the time when a producer is in the position to simply write off a customer due to their attitude (although, of course, there are limits).

So this is where being customer-facing (as you could call us Microsoft bloggers and newsgroup people and such) can turn nasty. There have definitely been customers who were just plain unpleasant to deal with – mean, nasty, totally unreasonable and completely without the basic respect that one should afford another simply on the basis of their shared humanity. I don’t mind admitting that they have caused more than a few episodes of anguish on my part, made worse by the fact that I was totally unable (and, I might add, personally unwilling) to express how I really felt about them. I doubt that they thought that I particularly liked them, but I doubt that they could know exactly what I was feeling as I was interacting with them.

Thankfully, though, those experiences have proven to be the exception rather than the rule. By and large our customers – even though who vehemently disagree with me on some issue or another – have been a pleasure to deal with. It’s never fun dealing with someone who’s upset or angry with some action that you or your company took, but as long as the conversation is held within the context of basic human respect for each other, it generally turns out to be nothing but a positive (if sometimes a difficult) experience. As for the jerks out there, well, what can you do? To use some pseduo-Latin (and hoping my high school Latin teacher never sees this!): Illegitimus non carborundum.

Answer their questions, win a LCD monitor!

So Devsource is running another trivia contest, this one to win a Dell LCD monitor. I don’t have any questions in the contest this time, but I thought I’d mention it because of the peculiar result my comment on the previous contest has had. Since the contest, I have gotten a steady stream of comments from people around the world who obviously Googled something like “win a laptop,” found my page, didn’t bother to read it, and just put in a plea for me to please, please, please send them a free laptop. Same goes for the entry that I wrote about an offer for a free VB book (at least that one’s slightly more plausible). So now I want to see how many comments I can collect here from people who want me to send them a free LCD monitor. Or maybe the Google competition’s going to be too fierce. (I’ve noticed my “win a laptop” entry has slowed down comment-wise, so I’m guessing I’m no longer high enough in the results.)

Server Intellect rocks!

I don’t think I’ve said this before, so let me say it now: Server Intellect, the company who hosts my blog, is a great web hosting company! A while back when I decided to stop hosting my own blog, I moved everything over to them on the recommendation of a co-worker and it’s been a real pleasure ever since then. Last week there were some problems with my site (not of their doing) and they proactively noted the problems, took some steps to fix them and then dropped me a very nice note letting me know they’d taken care of it. Great customer service all around…

If you’re looking for a .NET enabled web host (or just a regular web host), I highly recommend them!

Default Instance Considered Harmful…?

Way back in the mists of time (better known as January), I wrote two entries on the default instance feature we’re reintroducing in 2005. The first talked about what default instances are and the second talked about why we thought they were a good idea. I promised at the time to talk about the criticisms that have been leveled against the feature “soon,” but that “soon” has turned into “two and a half months or so.” This is partially because my work load suddenly ramped up, but it’s more because my blog entries and the accompanying comments prompted another round of internal discussion over the feature. That, unfortunately, took much longer than I wanted it to, which further delayed this (since I didn’t want to say one thing only to have to take it back later). So I apologize for the delay in getting back to this.

Anyway, now that we’re past that, the objections to default instances seem to tend to boil down to two major issues:

First, although default instances exhibit most of the attributes of singleton objects, they are really only “semi-singletons” because they can still be instantiated. In other words, in addition to saying Form1.Show(), you can also say “x = New Form1()” and then “x.Show()”. When you use New, you’re creating a second (or third or fourth…) instance of Form1 that is totally separate from the default instance. The relationship between the singleton form and the instantiated form can be obscure at best, causing confusion between the singleton nature of the default instance and the multi-instance behavior of the normal type.

Second, a default instance that can be accessed through the type name (at present, only form default instances do this) erases the distinction between instance and shared members. When I say “Form1.x,” I have no way of knowing, without looking at the object browser or MSDN help, whether “x” is a shared member or an instance member.

(There is a third objection that because non-dialog Windows Forms lose state when they close, default instances are not as useful as they were in VB6. This is a limitation of the Windows Forms design, not VB – when a form closes, everything on the form is disposed, including the controls. Bill proposed a workaround that, I’ll confess, I don’t entirely understand, but it’s something we’re talking to the Windows Forms teams about, although I wouldn’t expect anything for VB 2005.)

The bottom line is that both of the major criticisms of default instances are valid. Despite their usefulness, they do create some semantic confusion that did not exist in the language prior to their re-introduction. Why, then, did we do it? In the end, we felt that, on the balance, the semantic confusion created by the feature was greatly outweighed by its usefulness. Working with forms (and, in VB 2005, web services) as default instances is a very natural and understandable way of doing things, regardless of experience level or knowledge of the language. In our continuing quest to make Visual Basic the most approachable and easy to work with language, this seemed like a very natural feature, not just because it happens to be compatible with VB6.

The standard rejoinder to this line of argument is, “well, fine, re-introduce the feature if you must, but why must you make me have to deal with it?” In other words, “why aren’t default instances optional?” This has been the subject of many long-running discussions internally and we’re open to the idea, but found no good way to do so in this release. We considered introducing a single instance/multi-instance mode switch into Windows Forms, but that would mean that changing the instancing mode of a form would cause drastic changes in the way the form was used in code. Thus, it would be vital to choose up-front whether a form was going to be single instance or multi-instance, and woe be unto the developer who chose incorrectly. We just didn’t feel that was a good user model for the feature.

The other major idea we considered was introducing some kind of configurable warning into the product that would allow people to turn the use of a default instance into a warning or error. This seemed much more palatable, but ultimately died because of what it would imply: warnings and errors indicate code that is probably or definitely wrong. They’re intended to ferret out errors, so adding a “warn on use of default instance” warning would imply, well, that using a default instance is an error, which is something that we don’t believe.

So, where does that leave us? One idea that we’ve started to kick around is the idea of integrating the concept of a “programming style” into the product. In other words, if your programming style is to not use default instances, great – you set that style parameter and then the compiler will warn you when you violate that style. Once you start down this path, you can imagine a great number of possible style settings that the compiler could flag – things that are entirely legal and valid, but which someone somewhere might not like. Unfortunately, this kind of feature is well beyond our VB 2005 schedule. However, as we start to think beyond our existing release, we’d love to hear what you think about the idea!

(For the less-aged among my readers, the title of this piece refers in an ironic way to the seminal paper Go To Statement Considered Harmful by Edsger W. Dijkstra, one of the founding luminaries of the computer science field. I would also note in passing that Visual Basic still has a GoTo statement…)

So it has a name… the Sapir-Whorf hypothesis.

A long, long time ago I riffed a little bit on the question of “why do we have VB and C#?” The idea I was trying to struggle towards was that even though two languages may share many similar constructs and be able to express roughly the same thing, design decisions on little things can make a big difference in the experience of using the language. Now I learn from Dave Remy that this is hardly a new idea and even has a name: the Sapir-Whorf hypothesis. There’s even a discussion about how it might or might not apply to programming languages. Well, you learn something new every day…

(And, yes, I am a geek. When I first saw the phrase “the Sapir-Whorf hypothesis,” my first thought was, “what does this have to do with Star Trek?”)