SDR Time

Development has currently come to a complete halt for me.  This is partly due to the fact that i'm a lazy bum, and i'd rather loaf around than earn my keep.  However, beyond that we're currently meeting with our C# Customer Council conducting an Strategic Design Review (SDR) and it's pretty much infinitely more useful for me to be partaking in this process rather than just coding.  Why?  Well it would help to start out by talking about what an SDR is really about?  As you've seen from many posts of mine the C# team is desperate for feedback of all sorts from our users.  The SDR process is about the most intimate way we go about getting that feedback.  Rather than using things like blogs which use electronic communication to target tons of users, we spend several days with a small number of developers in very cozy rooms where everything is done face to face.  For me, this time is completely about shutting up and just listening.  We meet with this group periodically and we feel that they’re a good representation of our users.  i will rarely talk during the SDR (unless there is something brought up that i am absolutely the best person to take care of it), and instead i want to get maximum value by getting a chance to learn about what these developers are looking for and what they are finding unsatisfactory about our current tools and language.  Any and all feedback is welcome (and encouraged), and provides a level of closeness that we’ve found tough to replicate through any other forum.

We’re always rolling around many different ideas and trying to determine what we think is the most important stuff to work on, and with the aid of these people we can reevaluate our positions. This is a time for us to hear: “omg!!  Why on earth are you working on that?  That is the most useless thing i’ve ever seen.  Why aren’t you working on this other thing instead since this is causing pain for tons of businesses and developers and any help here would be far more beneficial than anything else you could do!”.  Or they might say: “yes!  That’s a great start!  But in my business it would be useless in its current form.  However, if you just tweaked this slightly then it would fit the bill”.

And, as one member even commented, (paraphrased) “dogfooding only gets you so far.  It lets you build software that works for companies exactly like MS.  But we’re not like MS and you need to understand how our needs differ”

One of the big eye openers is how little these people care about the things that i am passionate about.  Instead they are passionate about areas that i am either unexcited about or, worse yet, areas that i know almost nothing about.  This is a necessary thing for me to be reminded of and it tells me that i need to do a whole lot of learning about an enormous amount of technologies in order to really be able to produce software that these people find useful.  i’m a language guy who loves building tools to help out developers.  i like working mainly on what we describe as “code-focused” tools.  i.e. the features that interact with the user as they’re editing and are really about allowing you to create great, maintainable code.  However, for many of the participants here, it’s the domain specific business logic that they’re always thinking about and working with the code is just a means to and end.  Instead, they get the most benefit from the high level APIs that that implementing that domain specific logic far easier.  It’s also about easing the pain of connecting the different domains that they’re going to run into when creating the software their client needs.  For example, easing the pain of connecting databases to web front ends, to installing rich apps, to providing thin clients for support teams to use, etc. etc. etc.

So the interesting question we ask ourselves is: “Is it possible to further the language in ways that ends up making that job much easier?”   “What about the tools?”  “What about the APIs?”

This SDR then gives a good gut feeling about what we should be working on and it gives us focus for further designs in the coming future.  Then, as time passes we will gradually expand out this information to larger and large circles, eventually leading up to our first public disclosure.  At that point we’ll have done a fair bit of working with all sorts of customers to see the different needs that people have and we’ll have prioritized in a way that we feel provides the maximum benefit to the most consumers.  Then we get let the full community weigh in and let us know how they feel this.  Usually, things seem to be pretty much in agreement.  The choices we’ve made are generally in sync with most users.  There are usually slight differences into how important people think things are, but in general it’s a good match and is pretty easy to fix up.   Now, one of the times that where the community definitely felt that our decision was incorrect was in our decision to not do Edit-&-Continue.  But once we expanded out to the community we realized our error in not supplying this tool.  With the enormous feedback we received we realized that our st of priorities was decidedly un-optimal and needed to be drastically corrected if we really wanted to provide tool our customers would find useful.

i’m still completely committed to making VS2005 great and getting it out of our hands and into yours in a timely fashion.  i think you’re going to love Beta2, and the final release will be even better.  But once it’s in your hands, then i can’t wait to start working on all the stuff that’s going to come next.  i think you’re going to be blown away and are going to find the future of C# to be a very bright and promising one.


Oh, and just so you know, i love all forms of communication and i’m going to using as many as i can handle to get to know what the community wants.  So please continue to send me the feedback that you’ve been so generously providing up to now.  Trust me when i say that *every* single messages is listened to, and we will consider all of them when making our future plans.  If you have ways that you think the platform should develop, or if you’re unhappy about the choices we’ve made so far, please continue to let us know.  Together we can end up making the best C# possible! :)


Edit: I was wrong to imply that the customer council told us to not do E&C. Rather, when we asked for prioritization they wanted Refactorings over E&C, and *we* felt that we couldn't pull off both in one product cycle.  However, given the huge response from the community (as well as the customer council telling us it was important), we reprioritzed our feature set later on in the game so we could do both of them.