Dmitri Gavrilov
Principal Software Development Lead
Exchange Server

 Roles
 Career paths
 Product release cycle
 Tools





Three main roles: dev, test, product management
Product Manager (PM):




Owns scenarios
Does not write code
Interaction with customers, other teams
Writes functional specs
Dev (SDE):



Owns product code
Fixes product bugs
Writes design specs
Test (SDET):
 Owns product quality


Writes test code and fixes test bugs
Writes test specs

 Managers
 Lead, Manager, Director/PUM/GM
 Executive (a hierarchy of VPs)
 Architects
 Super-smart individual contributors
 Contractors
 Manual testing/deployment/operations
 Hourly pay, can only work 9 months out of 12.

 User Experience/docs/help writers
 Support
 Escalation Engineers (frontline support, mostly in India, answer FAQs)
 Support Engineers (second line of defence, know product well, can solve most problems)
 Critical Problem Resolution Engineers (virtuoso debuggers)
 Premier Field Engineers (dedicated to important customers)
 Product Marketing
 Sales

Level
Title
Work
Scope
Roles
SDE
59-60
SDET
PM
Do
Feature
61-62
SDE II
SDET II
PM II
Own
Component
63-64
Senior SDE
Senior SDET
Senior PM
65-67 68+
Principal * Partner *
Drive
Component lead
Individual Contributor (IC)
Understand business
Product
Leadership
Product line
Industry
Architect
Lead
Manager
Executive




Milestones (6-9 months)
 MQ (quality)

Dev/Test: fix postponed items from prev release

PM: Prioritize scenarios


M1-Mn (dev milestones)

Dev/Test/PM: Implement features
MP (polish)
Later milestones are released to external testers:
 Internal testing (dogfooding)



Public Betas
Release Candidate
RTM/RTW (release to manufacturing/web)
SE (Support Engineering): hotfixes, service packs








Criteria for taking/not taking bug fixes
There are always more bugs in the product
Do you fix them now or in the next milestone/release?
Bug bar is raised towards the end of milestone
Highest setting just before RTM
After RTM, the bar goes down somewhat


Safer to release a hotfix to a set of customers that need it
Hotfixes are rolled into service packs
When bar is high, bugs are triaged/approved by the War
Team (release management people)
 You come to war and defend your bug: prove why it meets the bar.




High









High impact or frequent crash/hang, serious perf degradation, scale, config that will prevent production
Core scenario with high impact with no reasonable workaround
Data corruption or loss
RC blockers or RC failures
Very high impact supportability bugs that could save lots of time and money down the road
High impact globalization/localization issues
DOA and Test Pass blockers
CPX issues that prevent from shipping (Policheck, API scan, etc)
Security Issues rated as “Critical” based on the SWI guideline
Medium





Critical partner dependency issues (including other component teams, ExRAP and PSS)
Regressions
Functional behavior that is clearly against the design
Security issues rated as “Moderate” based on the SWI guideline
Supportability issues
Low





Code cleanups
Performance improvements beyond the stated goals
DCRs that are not essential to E12 SP1
Branding
Bug with an easy workaround







Product Studio: database of bugs
Tree of components
Bug types: code bug, Design Change Request, Work Item, Customer
Escalation, etc…
Bug lifetime:




Opened
Triaged by component triage team, assigned to a dev
Dev works on the fix
Tester verifies the fix



(optional) Bug is marked as ReadyToCheckIn, to be approved by war
Dev checks in the fix, resolves the bug
Tester verifies the bug is fixed, closes the bug
Mgmt uses bug database to track progress
Bug resolution: Fixed, NotRepro, Duplicate, WontFix, Postponed,
External.

 Database of source code: Source Depot
 To work on a file, you have to check it out
 Multiple people can check out a file
 At check in, you may need to merge with other people’s changes, resolve conflicts
 Change history is preserved (incremental changes)
 Checkins are associated with bugs
 Branches are super powerful concept
 One primary product branch
 Code forked near milestones



Smoke






Automated test running system
Smoke must be run before checkin
Builds product with your changes
Deploys on multiple test topologies
Runs tests
Tests are prioritized, depending on which code is changed
TopoBuilder




Automated topology deployment
Topologies: from single machine to complex multi-domain multimachine topologies
Quotas
Lifetime management: machines are automatically reclaimed into the common pool after a while.