“Perfection is reached not when there’s nothing left to add, but when there’s nothing left to remove.” – Antoine de St. Exupery

Your feedback on Community Technology Previews is invaluable to us in the pursuit this lean perfect solution.  Working on a first version technology (a “v1”) is both a thrilling experience and an exercise in restraint.  It is so easy for us to see opportunities – oh, if we added this property here, this method there, this special case in this function, we’d make things so much easier to achieve a few scenarios here and there which may or may not be common.  It requires a lot of control to do this with an API.  Everything that we add to an API creates a number of drawbacks to the consumer of the API, which include:

1)      A morass – More features leads to more API and documentation to wade through to find what you really need,

2)      Complexity begets chaos – the more complexity to the system, the more likely that things will not interact as you intended, since there are so many things to interact together

3)      Tension between quality, schedule, perf and features – there is no way that we can add functionality without adding more work that detracts from other parts of the project or the schedule, and

4)      Instant legacy – stuff that most of you don’t need in this release, but we need to pay the cost in supporting in future releases on the off chance that a solution or more out there depends on it, causing us to have to make trade-offs on quality and schedule for-(pretty much)-ever.

I’m sure that you can think of more drawbacks now that we’re down this path. 

But We Don’t Want to Miss Anything Important, Either

On the other hand, we want to ensure that Parallel Extensions to the .NET Framework does have everything that is needed to get the job done.  Internally, we spend as much time as we can “dogfooding” or using our own technologies (ref: dogfood company reps tasting their wares before stocking shelves).  But we miss things.  It’s hard to both build the technology and build every real world application imaginable.  Simply put, we do not know your specific needs, so please tell us.  If we miss something key, let us know.  And the more people who let us know, the more information we have to make a good decision on it. 

We cannot and should not act directly on every piece of feedback (as stated above), but we want to act on the right stuff. 

What Feedback Helps?

In short, all of it.  Even if you cuss us out, we learn from that; though, we prefer sweeter delivery vehicles.

These are the types of feedback that really, really help:

Please let us know where we completely miss the mark, so that we can change course if appropriate.

Please let us know what you use so that we don’t remove it.

Please let us know what you don’t use, so that we can consider removing it.

Please let us know what you want, but we don’t have so that we can consider adding it.

Please let us know what you (will) do with our tech, so that we can design specifically for that.

This is why we release CTPs and why we ask for your help.  And we use it, we’re greedy for it.  In the end, you’re presented with a better technology to meet your needs.  It is easy to see why we do this.  The cycle is virtuous.  Your feedback helps us help you help us help you…