On Achieving Perfection –or– Why We Love Your Feedback (and Why You Can Love Giving It)

On Achieving Perfection –or– Why We Love Your Feedback (and Why You Can Love Giving It)

Rate This
  • Comments 14

“Perfection is reached not when theres 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…

 

Leave a Comment
  • Please add 7 and 6 and type the answer here:
  • Post
  • Well, since you asked...

    I'm not using the parallel CTP, but I'm following this blog closely and with great interest. Some of this is just that I don't have much time for programming (I'm a student), but some of it is that I'm generally wary of using pre-release APIs. (I don't wanna try ASP.NET MVC or .NET SP1 or even Silverlight 2 until they nail themselves down, for example). So take my 'feedback' with a grain of salt, since it isn't based on actual experience.

    That said, what I'm most excited about is PLINQ. Everything else would require some kind of shift in my thinking; I don't generally code most of my applications in a task-oriented way, but more in a typical Windows or Web Forms model: UI back-and-forth with the code, which sometimes calls into a library which does all the data processing in small chunks at a time. But for those data-processing steps, I've fallen in love with LINQ; it's really true that almost everywhere I have a foreach I can replace it with a LINQ query that makes things so much nicer in a lot of ways. In essence, I end up using LINQ for almost all of my data processing tasks.

    So to me I'm really excited by the possibility of being able to have this scenario play out:

    * Hey, the code spends a lot of time here in this LINQ query. Wonder if I could parallelize it?

    * Yeah, OK, looks like nothing there depends on previous data; everything is processed independently. Let's try this then...

    * ALL OF THE ACTUAL WORK: slap a .AsParallel() onto the end of the query.

    * Run some tests and make sure things are still working/are working faster.

    * Done!!

    Actually once this summer rolls around I'll most likely try to implement that exact scenario on one piece of code that I have in mind. Right now it gets all the links on a web page, then downloads/processes each linked page's contents sequentially, because I didn't want to bother with threading for this quick hacked-up application. I'm hoping that I can just slap an .AsParallel() onto the end and get some nice results. So that's my use case.

    It's quite probably that PLINQ and how easy it is (appears to be?) would just be a "gateway drug," for me, and the rest of the framework would start showing up all over my code sooner or later. But subject to the "I haven't actually tried any of this" caveat from the opening paragraph, the PLINQ use case seems like a no-brainer.

  • At Microsoft we are always looking to get feedback about our products and technologies from communities

  • Hi All, Parallel Extensions simplifies development by providing library-based support for introducing

  • Вышел второй CTP для Parallel Extensions - библиотеки позволяющей облегчить напи

  • Free performance lunch is over. During the past few decades we witnessed continuous growth of single

  • PingBack from http://vladvino.wordpress.com/2008/06/03/parallel-extensions-to-net-june-2008-ctp/

  • Here's a new one with the June CTP:

    https://connect.microsoft.com/feedback/ViewFeedback.aspx?FeedbackID=348962&SiteID=516

    I really hope this is changed as many subtle bugs will undoubtedly occur....

    Thanks!

  • On top of Bill Gates announcements at the Microsoft Tech·Ed North America 2008 Developers conference,

  • I've built a cool API that makes task-oriented programming more natural and understandable. If you are interested in my implementation or a chat, please contact me: paymon [at] geeks [dot] ltd [dot] uk.

    using (var tasks = new ParallelRunner())

    {

    tasks += Method1;

           tasks += ()=> { x = x + 2; };

           tasks += delegate { /*Do anything*/ };        

    }

    // All taks will have been completed by here.

  • “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 o

  • I hope a lot of effort goes into the documentation for using the TPL. Threading is such a beast of a topic and easy to miss subtle details.

  • Paymon, your example can be done very easily on top of the Task Parallel Library, e.g. something like:

    class ParallelRunner

    {

       private List<Task> _tasks = new List<Task>();

       public static ParallelRunner operator +(ParallelRunner runner, Action a)

       {

           runner._tasks.Add(Task.Create(delegate { a(); }));

           return runner;

       }

       public void Wait()

       {

           Task.WaitAll(_tasks.ToArray());

           _tasks.Clear();

       }

    }

    Then I can just write code like yours:

    var tasks = new ParallelRunner();

    tasks += Method1;

    tasks += ()=> { x = x + 2; };

    tasks += delegate { /*Do anything*/ };

    tasks.Wait();

    Hope that helps.

  • Kevin, regarding documentation, we agree :)

  • PingBack from http://outdoorceilingfansite.info/story.php?id=58829

Page 1 of 1 (14 items)