{"id":2271,"date":"2013-05-08T06:04:16","date_gmt":"2013-05-08T06:04:16","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/bharry\/2013\/05\/08\/some-thoughts-on-a-comment-about-vs-2012-3\/"},"modified":"2024-04-12T13:36:01","modified_gmt":"2024-04-12T20:36:01","slug":"some-thoughts-on-a-comment-about-vs-2012-3","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/bharry\/some-thoughts-on-a-comment-about-vs-2012-3\/","title":{"rendered":"Some thoughts on a comment about VS 2012.3"},"content":{"rendered":"

Yesterday, I got a thoughtful comment from Dean on my post about Update 3.\u00a0 I sat down to write a response this morning and it turned into a but of a novel (in fact, the blog says it\u2019s too long to post as a comment \"Image<\/a>).\u00a0 So I\u2019ve turned it into a post.\u00a0 Here was Dean\u2019s comment:<\/p>\n

Brian,<\/p>\n

I looked at the list of fixes, you weren’t kidding when you said small.\u00a0 Are those just the major ones (crashing)?\u00a0 There are a whole lot of things logged on Connect that when added together really stifle productivity (many involving the editor with intellisense, syntax highlighting, etc.).\u00a0 I get nervous at this point in a VS life-cycle because I fear that the bugs I care most about will once again get worked on for the next major version.\u00a0 We spend money on the product and the window of time for things getting fixed is unbelievably tiny…before MS turns off the lights\/closes shop until the next version.\u00a0 The new update cycle is great, I just hope it is not merely SP1 in chunks…I hope you still give updates to the product all along the way up until the next version.<\/p>\n

-Dean<\/p><\/blockquote>\n

 <\/p>\n

And my reply\u2026<\/p>\n

@Dean, I try not to kid \ud83d\ude42\u00a0 I’m not going to swear that’s every single bug fix. Plus there will be a few more fixed between now and the final release – for instance, I just heard that we are fixing a few important Blend issues and those fixes didn’t make the RC.\u00a0 It’s not an incredibly small list – I count 59 bug fixes.\u00a0 I’m not sure whether to feel proud or ashamed that 34 of them are in my team \ud83d\ude42\u00a0 I think the answer is proud, though I suspect this is an eye of the beholder issue.\u00a0 A story…<\/p>\n

I was speaking last week with one of our test managers and he said to me…<\/p>\n

People in shiproom don’t know what to make of us.\u00a0 We bring so many more bugs to be fixed than any other team in VS that they just look at us sideways.\u00a0 But, my feeling is that if a customer reports a bug, we should just fix it.\u00a0 We’re doing the update anyway and there’s no point making the customer wait.<\/p><\/blockquote>\n

Aside – shiproom is a process we have of sharing the changes that each team is making as we get close to the end of any release that allows for peer review and feedback.\u00a0 The purpose is to help slow down the churn, reduce the risk of regression and warn other teams of any changes that might impact them.<\/p>\n

It was a proud moment for me.\u00a0 I’ve spent the better part of 12 years arguing for a different way of thinking about this kind of thing.\u00a0 I grew up in startups where virtually every customer felt like the difference between going out of business or not.\u00a0 I spent 30% of my time on tech support and generally gave same day (or at most a couple of days) turn around on bug fixes if a customer had an issue.\u00a0 I’ve always believed that trying (look, I understand that you’ll never fully succeed) to make each and every customer happy is important.\u00a0 And the connection between developers and the problems customers face is an important feedback loop that forces learning over time.<\/p>\n

I don’t want anyone to think this is a simple “motherhood and apple pie” vs ignorance issue.\u00a0 There’s a legitimate debate to be had.\u00a0 First, every time we fix an issue we have a non-zero probability of introducing a regression that our testing misses.\u00a0 Customers tend to be super unhappy if they get a fix for one problem only to find a new problem they didn’t have before.\u00a0 Further, we all know interruptions are bad – they sap productivity.\u00a0 Having to stop what you are doing and investigate a customer reported issue (which often turns out to be a configuration problem), produce a fix, test it and deliver it can really reduce the overall volume of value delivered.\u00a0 Further, fixing every issue any customer reports can cause you to spend an inordinate amount of time fixing issues that affect relatively few people while the bulk of your customers wait for value.\u00a0 It’s not a simple trade-off and neither extreme is the right answer.\u00a0 It’s a balance and it all comes down to the values to apply to weigh that balance.<\/p>\n

As for the instability introduced by regressions, I argue that some regression rate is acceptable as long as your time to repair is sufficiently short.\u00a0 While a customer will be frustrated by getting a new bug along with their fix to the last, as long as it doesn’t happen too often and you fix the new bug quickly, the net result of fixing people’s issues more responsively is a win.\u00a0 Reasonable minds can disagree on what rate is considered acceptable.\u00a0 The lower you want to drive the rate though, the less churn you can tolerate and the less frequently you can release.\u00a0 Generally your tolerance also varies by the kind of component you are working on, the ease of deploying updates, and many other factors.<\/p>\n

Now, again, before someone jumps to calling me a hypocrite, let’s talk about Team Project Rename.\u00a0 There’s an “issue” that has existed for a long time and we’ve done nothing about it (right Allen?).\u00a0 Could we?\u00a0 Of course, it’s just software – anything can be done.\u00a0 So that must mean we have decided not to despite it being one of the top customer generated requests.\u00a0 Brian, you’re a hypocrite.\u00a0 I like to think I’m not but you can judge that for yourself.\u00a0 As I said, it’s a balance.\u00a0 This is probably one of the things I hang my head in shame about.\u00a0 We made some decisions many many years ago that, in retrospect, I would do differently.\u00a0 The ramification of those decisions are that Team Project rename is hard – it shouldn’t be, but it is.\u00a0 We’ve costed it a couple of different times over the past several years and it always comes back as months and months of work with high regression probabilities.\u00a0 That doesn’t mean we’re ignoring it.\u00a0 I still very much want to do it but we’re taking a longer road to get there.\u00a0 For a while we just decided to “live” with the problem.\u00a0 Now we have a plan but it calls for making changes to “undo” some of those decisions we made many years ago that makes it hard.\u00a0 Once we get that work done, we can do rename.\u00a0 All I can do is apologize for how long it is taking.<\/p>\n

Back more to your point Dean.\u00a0 Yes, Update 3 is likely the last of the updates to the VS 2012 line.\u00a0 Of course, we’ll still continue to fix any critical issues people find but we are winding it down and focusing on VS V.Next.\u00a0 I’d like to think many of the issues you refer to will get addressed there and, if not, I hope we’ll get to them in the V.Next update train.\u00a0 Referring to the above – Update 3 is the update where we slow down the churn, address remaining high impact customer issues and any regressions introduced in Update 2.<\/p>\n

When you say the window is “unbelievably tiny”, I don’t think I agree.\u00a0 Of course we tried to get as much customer value and feedback incorporated into 2012 RTM as we could and then followed with 3 updates over a period of 9-10 months in which we delivered, in the aggregate, a tremendous amount of stuff – much of which was directly driven by customer feedback (e.g. Desktop Express SKU, C++ XP targeting, Kanban support, Blue theme, and dozens of more significant improvements – and, hundreds of bug fixes).\u00a0 While I can understand it’s frustrating that we didn’t get everything – or even all the most popular ones, we did make a lot of progress – and we\n‘ll keep making progress in the context of V.Next.<\/p>\n

I also don\u2019t think it\u2019s \u201cSP1 in chunks\u201d.\u00a0 The kinds of changes we\u2019ve put into the updates go FAR beyond what we would have historically included in a Service Pack.\u00a0 Service Packs had an \u201caura\u201d that they only contain bug fixes and while that was never strictly true \u2013 any time someone proposed a Service Pack change that didn\u2019t smell like a bug fix, there was a lot of justification that had to be done.\u00a0 One of the fundamental mindset changes with the move from \u201cService Packs\u201d to \u201cUpdates\u201d has been that the primary value of Updates is new value \u2013 and sure we\u2019ll fix a lot of bugs too, but that\u2019s not the focus.\u00a0 Read my posts on the updates and you\u2019ll that generally the bug fixes are a footnote.\u00a0 They are all about the cool new capabilities we are enabling.<\/p>\n

I’ve exposed a lot of flank here – so I suspect it may generate a lively conversation.\u00a0 But, hopefully it sheds a little light on how I think about it (of course, only one person in a large company – so don’t construe this as any kind of official policy).\u00a0 As always, I’m happy to engage in healthy debate and learn from customers and from mistakes.<\/p>\n

Thanks as always for listening,<\/p>\n

Brian<\/p>\n","protected":false},"excerpt":{"rendered":"

Yesterday, I got a thoughtful comment from Dean on my post about Update 3.\u00a0 I sat down to write a response this morning and it turned into a but of a novel (in fact, the blog says it\u2019s too long to post as a comment ).\u00a0 So I\u2019ve turned it into a post.\u00a0 Here was […]<\/p>\n","protected":false},"author":244,"featured_media":14617,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[5,4],"class_list":["post-2271","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized","tag-tfs","tag-visual-studio"],"acf":[],"blog_post_summary":"

Yesterday, I got a thoughtful comment from Dean on my post about Update 3.\u00a0 I sat down to write a response this morning and it turned into a but of a novel (in fact, the blog says it\u2019s too long to post as a comment ).\u00a0 So I\u2019ve turned it into a post.\u00a0 Here was […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/bharry\/wp-json\/wp\/v2\/posts\/2271","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/bharry\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/bharry\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/bharry\/wp-json\/wp\/v2\/users\/244"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/bharry\/wp-json\/wp\/v2\/comments?post=2271"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/bharry\/wp-json\/wp\/v2\/posts\/2271\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/bharry\/wp-json\/wp\/v2\/media\/14617"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/bharry\/wp-json\/wp\/v2\/media?parent=2271"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/bharry\/wp-json\/wp\/v2\/categories?post=2271"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/bharry\/wp-json\/wp\/v2\/tags?post=2271"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}