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.