Thursday, October 13, 2005

Deadlines

There are many little deadlines in the Office development cycle as we try to stabilize the product a bit. To be fairly vague, checkins are restricted during those times to fix "important" bugs only—the ones where the problem is bad enough and the fix is cheap enough that it's "worth it." A bug where the page isn't "dirtied' when you do things to it, so you aren't notified to save when you close the program, is pretty bad. A bug where every word on a page encoded in UTF-8 shows up as a spelling error is bad but easily worked around, so it probably wouldn't be allowed to check in. The way things work is that for the duration of the "chill," the bar is raised each week until at the end only the most important fixes can be checked in. This isn't something Microsoft; this is just a common technique of controlling change in software.

Clearly you should work in priority order, fixing the bad bugs first and the less significant bugs later. But, let's say it's four weeks until beta 2 ships, and you know that after beta 2, you won't be allowed to fix little silly things like buttons being two pixels too far to the right, because they aren't going to be willing to accept the risk of breaking things for little silly bugs. You'll never have time to fix all of your important bugs in time to fix that silly bug.

A naughty developer fixes the little stupid bug before the important ones, so it's sure to be fixed in the final build of beta 2. The other ones are big, nasty issues with bad problems, so they'll definitely still let you check those in later. The point of these chills is to increase stability and get rid of the bad bugs, but they can backfire: they can cause people to frantically check in lots of fixes for little insignificant things at the last minute before the bar goes up and suddenly those aren't important enough to fix right now.

I haven't been around here long enough to see how often this kind of thing happens on my team. I think that so far we've done a good job of balancing things and bending the rules when appropriate. For example, right before a recent chill to produce a stable version for people all over Office to use for their daily work, I checked in some changes that made error messages more clear and helpful right before the deadline when those changes would have no longer been accepted. That seems to be against the spirit of the chill, but it was a super-low-risk change, and it had a positive impact.

I guess you just have to balance bending the rules to make the product better with following the rules to make the product better.

No comments: