Alex Kipman - Inside a MS Build Bug Triage meeting

Interesting.  I love these "behind the scenes" type of videos.

This reminds me of how the other night my wife rented a movie ("The Secret Lives of Dentists" - not really recommended) and at least half an hour of the movie was about the family (couple with 3 small kids) all getting sick with the flu. We ourselved have 2 kids about the same age as the ones in the movie.

My reaction was "Why do I want to watch a movie of something I go through personally that's probably the most unpleasant thing I have to do?" The same applies to watching a video of bug triage.

Though perhaps the target audience in this case isn't other software product managers.

Next up how about a video of a code review?

Great idea. I'll see if I can't get to sit in on a code review.

BinaryBoy wrote:

Interesting.  I love these "behind the scenes" type of videos.

I agree. Yes, there are issues of non-disclosure for the sake of competition but the Channel9 Team should continue to walk that thin line!

As a tester who's life's work is basically shredded before his very eyes on an almost daily basis* by a triage team, I find that for the most part, the whole process of triage is one of those things that is usually best left to the imagination, kind of like sausage making.


*Note:  This doesn't actually happen... Usually.

well yeah kinda interesting to see for once but jeez ............ could you go any slower????

I presume this was 10 mins for Scoble and his camera before they actually had their meeting becuase if that was some of the real thing then I am suddenly no longer surprised it takes 3-4 years for an MS product to go through a revison.

Also, loved the two geeks on the sofa hiding behind 3 kilos each of 'mobile' hardware. hah

Well, obviously they were going slow to explain their methodology to me. But, good point, it'd be interesting to hide a camera in their office and find out how the sausage really is made.

We do go a bit faster in real life but not much.  We usually triage three times a week (1 hour blocks), and we usually cover ~20 bugs a triage session. 

During peak time we tend to meet everyday, and as ZBB approaches we could even impromptu meet every time a bug is opened.

I'm surprised you thought we were spending too much time on each bug.  If anything sometimes I feel we spend too little time. 

From our perspective Triage is what sets the quality bar across a given product.  Does a given bug meet our current bar, does it have reproducible repro steps, is this an instance of a more generic bug, does this really need to be fixed right now, is this a bug at all.  What context do we need to add to ensure the dev can be productive right away?  Is this a family of bugs, and can we link them together so the dev thinks about the entire family at once, thus not having to consistently context switch… etc etc etc. 

Spending a few minutes up front as a group working through these issues saves a bundle of time from a developer perspective since they only look at triaged bugs. 

When they look at a bug they know it meets the bar, they have enough information in it to be productive right away, and they don't have to worry about searching all over the place for similar bugs to fix while in this code. 

From my perspective this saves time when a dev actually gets the bug.  Amortized across all our devs and all the open issues we have, the time spent on triage is minimal and in my opinion very well spent. 

But that's just my $.02

akipman wrote:

We do go a bit faster in real life but not much.  We usually triage three times a week (1 hour blocks), and we usually cover ~20 bugs a triage session. 

etc...

But that's just my $.02

and all sounds like a lot of sense to me.

I guess i'm coming from a different background (investment banking) so for me products and development cycles are smaller and standard procedure for going through a bug/request list is heads down in a meeting room, burn through the list at double-time, somebody barking out the IDs + description, each party argueing over the priority.

To complete the picture, the office becomes a glass room, the desktop PC is linked to a OHP/Magicboard for all to see, all the laptop kit become O2 XDAs. oh and the dress code is raised a few hefty notches sartorially.

appreciate you're being friendly and polite... but clearly your're entitled to more than your $.02 worth, you run the MSBuild triage meeting...

Good luck with the product, i'm looking forwarded to using it as I'm making do with a copy of the BuildManager from the Patterns&Practises people with my own hacked in code on top.

I love this behind the scenes stuff. I worked for McAfee for a couple of years as a QA Engineer and this reminds me of the process we used there for managing issues found in the products (and there were many). Microsoft was always the golden standard we aspired to achieving for everything.

Hi,

I must say that I got interested in command line tools in the build process quite recently after having worked for the past 5 months on a j2ee project living and dogfooding latest eclipse wtp builds (I'm a .net-first-person, don't worry). There were things that just simply weren't in the IDE and it seemed natural to automate things outside the IDE. As ant was already integrated inside eclipse I decided I'd give it a go and although some results were easy to do other were obscure and strange, also the whole extension model to me is still incompehensive, why not choosing namespaces and a schema is a mistery to me.

Anyhow I had this thing in my faculty to use maven and as I'm one of those get-on-the-bandwagon-first people I decided to go with maven 2 that just got released. Wow, an eye-opener. Although still rough around the edges it gives a plugin-oriented way to manage the whole project lifecycle, all from a command line.

This brings me to my question. In the begining people were saying msbuild is like ant for .net, is it so or does it cover/will it ever cover aspects that maven/2 handles or will that be entering too much into VSTS terrytory?
thx

As usual media failure so couldnt watch the vedio ny one help plz............

I couldn't hear any audio when I downloaded the video.  I'm running a Mac with Snow Leopard, and the video would play in QuickTime Player with no audio, and VLC threw a bunch of errors about not being able to find the right audio codec.  Is anyone else having trouble with the audio from this video?  I'm going to try to watch this in a Windows VM later, but I was just curious.