Share via


Last Checkin Chicken

In the lifetime of every single project I've ever worked on, there's this little "game" that's informally played at the very end of the ship cycle.  It's never been formalized, but it's always been played (at least it was in every group I've ever worked in).

I call it "Last Checkin Chicken", it's kinda like the childrens game of "Hot Potato".

The way the game works is that no group wants to be the last group that makes a checkin in a particular release of the product.  I've never really understood why this is, maybe it's because we could have shipped one day earlier if it hadn't been for that darned last bug (which is silly, but). 

Since nobody wants to make the last checkin, whenever you make a checkin, you hold your breath and hope and pray that somebody else makes a checkin (and thus your checkin isn't the last one in the product).  If you ARE the last person making a change, then you don't win a prize or have to wear goat horns, or anything, it's just an invisible badge of shame :)

 

Last Checkin Chicken has varients.  Some groups hold informal office pools about which group is going to be the one that makes the last checkin ("Heh, I bet it's going to be the Glibert team, their code is just garbage", "Nah, it's going to be Snorklewanger team, they always find stuff at the last minute").  And within the individual teams, there is even further speculation, either by feature ("I know we've had trouble with the FLOMBERT feature, if it's our team that has the last bug, it's going to be in that feature") or developer ("Man, Terry writes crappy code,  bet the last fix is in code he wrote").

 

Ultimately, Last Checkin Chicken is something that developers do during the somewhat tense final hours of a project as a strange way of blowing off steam, ultimately it's harmless.

Comments

  • Anonymous
    October 25, 2006
    Checkin Limbo I just read Larry Osterman's post where he describes Last Checkin Chicken ( http://blogs.msdn.com/larryosterman/archive/2006/10/25/last-checkin-chicken.aspx

  • Anonymous
    October 25, 2006
    I made the check in to the last build of Vista beta1, and I am proud of it:)

  • Anonymous
    October 25, 2006
    I always referred to the phase after RC as 'waiting for disaster to strike'.  It rarely did, but it felt that was what I was waiting for until we could all look at ourselves and say 'ship it'.

  • Anonymous
    October 25, 2006
    The comment has been removed

  • Anonymous
    October 25, 2006
    Seems ironic, though. I would think it's a badge of pride that someone fixed a problem before ship, even if it was just an hour before ship. Doesn't Checkin Chicken push developers to want to defer fixes until a service pack, at least subconsiously?

  • Anonymous
    October 25, 2006
    5920 won't be it, it'll be a 5824+16*n.x+y where n and y are internal counters. Apparently the servicing guys have some magic formula that calculates why 16 and what x, n and y are, but I don't quite understand why.

  • Anonymous
    October 25, 2006
    For a while, my money was on the ship team stretching out the numbers and making RTM = build 6000 (Windows 6.0).  Doesn't look like it now, though.

  • Anonymous
    October 25, 2006
    > Doesn't Checkin Chicken push developers to want to defer fixes until a service pack, at least subconsiously? Perhaps, but at this point in the game, developers don't get to choose which bugs are fixed now and which are deferred, that's up the higher-ups. If you have a bug that needs to be fixed, you gotta fix it!

  • Anonymous
    October 25, 2006
    Dean, that's not totally true.  Developers have a HUGE influence in the decision. You're right, the individual developers don't get the final say (and haven't for quite a while), but the powers that be absolutely look to the developers for advice as about what bugs to take.

  • Anonymous
    October 25, 2006
    Actually, think about it and it doesn't sound as bad as the owner of the first bug filed after the RC/release. :P

  • Anonymous
    October 25, 2006
    Larry, well that's what I mean. Obviously it's the developers who have the knowledge about the code to decide whether the fix is feasible in the time that's left or not. But it's not like a developer would be able to just not fix the bug if he didn't want to.

  • Anonymous
    October 25, 2006
    Doesn't sound like a classic Chicked game to me. That would be 2 guys wanting to make the last checkin, and each waits for the other one to blink (checkin) first.

  • Anonymous
    October 26, 2006
    You Microsoft weirdos and your traditions. :-) (Pass the M&Ms) PS: Typo: varients -> variants

  • Anonymous
    October 26, 2006
    The comment has been removed

  • Anonymous
    October 26, 2006
    The comment has been removed

  • Anonymous
    November 02, 2006
    I did a Vista checkin for workaround audio hardware issue last night, I DON'T WANT TO BE Last Checkin Chicken for Vista!

  • Anonymous
    November 05, 2006
    I'm a bit puzzled by this for two reasons. (1)  With the number and severity (as evaluated by unpopular raters anyway) of bugs that are "won't fixes", you could have shipped 3 years ago when they were equally "won't fix". (2)  Once upon a time there wasn't much to be embarrassed about in fixing a bug even if it was fixed just in time, there was more to be embarrassed about in releasing it and maximizing the number of customers who would discover it.  The time for intentionally releasing bugs used to be alphas and betas not rc's.  But I guess that's ancient history.  If one of Microsoft's reasons for not fixing bugs is that it's more embarrassing to fix them than to not fix them, then that helps explain things.  I only wonder why one of Joel Spolsky's articles said that Microsoft had temporarily detoured away from the infinite bugs paradigm.

  • Anonymous
    November 08, 2006
    As you've almost certainly heard by now, we've finished. Windows Vista has shipped , and our mantle has

  • Anonymous
    February 26, 2008
    Some time ago, Larry Osterman wrote about the unofficial game of Last Checkin Chicken , wherein teams