Partager via

Big Step/Small step

  • Article

I’ve been spending the last couple of days responding to a customer bug complaining about the performance of the WinForms designer (WFD) when you use C# versus when you use VB.   For those who haven't used it, the WFD uses a round-tripping model where you can visually design your form, have it spit out the corresponding language specific code, edit that code (albeit with many restrictions) and see your changes reflected in the designer.

 

So why was the experience so much better in VB than in C#?  Well, certain parts of the WFD architecture is language neutral (specifically the GUI designer), however both the code-spit and code-analysis portions are implemented by the specific language teams.  Now, the code-spit part was no problem whatsoever, but as it turns out the code-analysis portion was a significant hot-spot for C# but not VB. 

 

Now, I’ve talked in the past how C# differs from VB in that they have a full incremental compiler whereas we have a more demand driven model that analyzes and deciphers code as necessary to satisfy the current request being made.  We also cache that information but aggressively invalidate that cache to insure that we're correctly understanding the code that you're changing.  (I’d prefer to have the VB model, but this is how it’s currently done for VS2005 and we have to work within those constraints).   Now, for the code analysis portion of the WFD we were doing things very naively (but at the same time very safely).  For example, when compiling each statement we were computing a lot of the same information over and over again instead of just using the information we’d compiled for the previous statement and just adding onto it.  We were also not caching when we could have.  For example in the statements:

 

                  this.ForeColor = System.Drawing.Color.Red;

                  this.BackColor = System.Drawing.Color.Black;

 

When we were trying to bind the identifiers “System”, “Drawing”, and “Color” in the second line we went through the same logic we went through in the first line.  So, I updated the code to deal with both issues and we have so far gotten dramatic performance increases from it.  However, even though I’ve spent quite a bit of time talking about this, this post is not about the WFD, profiling or the C# implementation.  What I actually wanted to talk about was the customer, his problem, and software development in general. 

 

In my last post I talked a bit about driving VS2005 to be shippable and making decisions about what issues need to be addressed, and which issues don’t meet the necessary bar.  It could have been quite possible that in the future this bug wouldn’t meet the bar, and it’s altogether possible that the fix I’ve created might not make it because it could be too risky.  i.e. we have a working designer right now, and it’s not clear if I might have missed something that will cause functionality to regress with this change, so is the risk of possibly breaking the designer worth the performance gain?

 

So what does that mean for the customer?  He’ll end up with another release where he wants to use C#, but finds the experience decidedly suboptimal.  I have no idea when the next version of the product will be, but I’d guess ~2 years after this one.  So that means that he’ll have to wait several years in order to get this issue resolved for him.  Personally, I'd feel terrible if that happened.  This customer has been great to us by providing us with an excellent scenario and performance data that they already collected, and they've been incredibly patient so far.  Normally i don't mind deciding not to fix a bug because i feel that it wont' relaly affect anyone terribly, but in this case i know full well that there is a company out there that would really benefit from this and if we don't work on this then they will be affected.

 

Now, consider two different methodologies we could be producing VS in: an incremental model with fast releases every few weeks or months, and an open source model.  I think both models would be fantastic for addressing this issue the customer is facing.  In the former we’d still have to tell him “sorry, we weren’t able to address this for VS2005.  But hey, here’s VS2005.1.”  In the latter, the community could provide a patch for this issue that the customer could use.  We could then examine the patch and incorporate it into the main source once we’d verified it wasn’t too risky.  It still wouldn’t get into the product for everyone until a later release, however, the customer’s problem would be solved and he wouldn’t be left waiting.

 

I’d really like the VS group to start investigating avenues that allow for this kind of rapid response to customer needs.  We’re never going to be able to ship the perfect product, and being able to address issues quickly rather than on a multi-year basis is something I think our customer want and deserve.

 

What do you think?

Comments

  • Anonymous
    October 10, 2004
    I like the open source idea, but the question is, would we still have to pay for a product that we've essentially helped to write? Visual Studio being free would be a GREAT problem for MS to have IMO :-)

  • Anonymous
    October 10, 2004
    The comment has been removed

  • Anonymous
    October 10, 2004
    Thank you, thank you, thank you... finally someone acknowledging the fact that Visual Studio releases are too much apart (regularly a few years).

    I would really appreciate it if MS would start releasing somewhat more aggresively. At least some features that are safe (in other words, do not introduce regressions) could be added this way. I won't even mention bug fixes...

    Actually, since original Visual Studio.NET there's been a button to check for service releases yet there hasn't been a single one yet - what's the deal with that? Isn't service release exactly this kind of thing you are proposing here?

  • Anonymous
    October 10, 2004
    I like the incremental release idea. It would be useful if it were combined with the ability to rollback an upgrade in case something broke that I couldn't live without. The problem now is that if something doesn't work right it can be a l-o-n-g time until a fix is released.

    Open source would be nice but it would take a lot of careful management to prevent it from mutating in harmful directions. I think that would have more benefit as a tutorial on how to write code then on how to get bug fixes done in a timely manner.

  • Anonymous
    October 10, 2004
    The comment has been removed

  • Anonymous
    October 10, 2004
    Updates/incremental releases every 6 months would work well. That should give enough testing time but also show customers that you are making progress.

    For our development group though, the reality is we do NOT update on every release. We have too much code and not enough time to spend a couple of weeks updating our developers and all the source code. Generally, we shoot for updating on every other release.

    It is also important that new releases work well with old releases. An example is VS2003 converting a solution so VS2002 can't use it. That causes a lot of problems. We need experience with new software tools before some developers/managers give acceptance for everyone upgrading. By having backwards compatibility, the early adopters can start using the tools on our projects and speedup the acceptance phase.

  • Anonymous
    October 11, 2004
    The biggest problem with doing releases every few weeks is that it's difficult to do anything more significant than small bug fixes or trivial features. Even a release every few months gives you about 8-10 weeks of code then a bunch of stabilization time. You never get to do refactoring or cleanup because you're always in crunch mode to ship. There are no beta releases where you can decide something just didn't work well and pull it.

    So while you get to spin on quick fixes, you don't get to do the really exciting new stuff.

  • Anonymous
    October 11, 2004
    The comment has been removed

  • Anonymous
    October 12, 2004
    Thank you, Thank you, Thank you - there are a lot of fixes (big and small), that I'm waiting for in the Visual Studio environment. Decuple framwork revisions from tools revisions and have releases evry 6-8 weeks.

    As for the concerns about frequent releases - look into any of the agile methodologies (XP, Crystal Clear, ...), they encourage it. It certainly seems to work for Eclipse.

  • Anonymous
    October 12, 2004
    Senkwe: I certainly hope we move to free releases for VS. :-)
    Unfortunately I'm not in management. I could move to management... but then i would be able to do the dev work i love!

  • Anonymous
    October 12, 2004
    Drazen: I agree. There are lots of little features I want to do that we just don't have time to do now and i don't want to have to wait years more until they're released.

  • Anonymous
    October 12, 2004
    ChrisBro: "The biggest problem with doing releases every few weeks is that it's difficult to do anything more significant than small bug fixes or trivial features. Even a release every few months gives you about 8-10 weeks of code then a bunch of stabilization time. You never get to do refactoring or cleanup because you're always in crunch mode to ship. There are no beta releases where you can decide something just didn't work well and pull it.

    So while you get to spin on quick fixes, you don't get to do the really exciting new stuff."

    I agree/disagree. I think you could do staggered released where you do work on some pretty big things (like generics), that require a lot of coordination to get right. but at the same time you could be producing your incremental work as well.

  • Anonymous
    October 12, 2004
    The comment has been removed

  • Anonymous
    October 12, 2004
    Mark: "Thank you, Thank you, Thank you - there are a lot of fixes (big and small), that I'm waiting for in the Visual Studio environment. Decuple framwork revisions from tools revisions and have releases evry 6-8 weeks."

    I'd definitely like that. It would be nice to be able to ship not connected to the runtime. And it would be even nicer to ship tools that weren't so tied to the IDE. not yet though. Sigh...

    "As for the concerns about frequent releases - look into any of the agile methodologies (XP, Crystal Clear, ...), they encourage it. It certainly seems to work for Eclipse."

    Our team has been focussing a lot on agile and XP and we'd like to move completely over to it. Jay http://blogs.msdn.com/jaybaz_MS talks about it a fair bit and is pretty passionate about it.

  • Anonymous
    October 15, 2004
    I'm still waiting for the bugs in VS2003 to be fixed

  • Anonymous
    November 07, 2004
    The comment has been removed

  • Anonymous
    August 24, 2005
    Your site is realy very interesting. http://www.bignews.com

  • Anonymous
    June 15, 2009
    PingBack from http://einternetmarketingtools.info/story.php?id=12620

  • Anonymous
    June 18, 2009
    PingBack from http://barstoolsite.info/story.php?id=2308