akipman
Alex Kipman is the Program Manager for MSBuild in the Developer Division at Microsoft. In this role, Alex helps drive the technical vision, design, and implementation of MSBuild, translating ideas into shipping features. Prior to joining Microsoft, Alex worked for a French consulting firm where he focused on software lifecycle and methodologies. Alex graduated from Rochester Institute of Technology where he majored in Software Engineering.
| Forum | Thread | Replies | Latest activity |
|---|---|---|---|
| Tech Off | MSBuild and Monad | 8 | Jun 30, 2004 at 1:31 AM |
Staff
Here is a list of Channel 9 staff members.
Alex Kipman - Building a mobile service
Dec 15, 2004 at 3:57 PMWell... your wish is my command:
http://alexkipman.members.winisp.net/channel9wikiimages/pro_box01.jpg
Enjoy... and don't say I didn't give you anything for the holidays!
Chad Royal - What gets into the bug database?
Oct 28, 2004 at 2:45 PMSo yep... we have a bug database for the bug database, and people all over the company use it
Great question!
Alex Kipman - Inside a MS Build Bug Triage meeting
Oct 27, 2004 at 4:49 PMWe 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