I also feel like this potentially unfairly makes the deva who have to work on more sensitive and critical sections look worse than they are. Perhaps it breaks because its a far more critical and sensitive space? Or am I way off base on this thought
The chicken was intended to be a silly friendly thing among our team, but not everyone seemed to take it that way. Yes, I and my team earned the chicken more than anyone mainly because 1) I seemed to check in the most code, and 2) our projects all started with the letter 'a', so we got the blame on days that multiple projects were broken.
Commonly we see many folks (particularly non-coding managers) treat a nightly build as some sort of indicator of developer competence or code quality. I have even heard anecdotes of devs being fired for breaking the build in a sufficiently large organization (but not the one with the chicken). A successful nightly build is one of those things that's trivially easy to measure and on the surface looks like progress. But of course, the easiest way to never break the build is to just never check any code changes in.
But I believe strongly that a nightly build should be treated as a tool like any other: in any large software project there will be times when a dev makes an honest mistake with the checkin process or simply cannot succeed at testing every interdependency by building on his own box beforehand. So give the devs something to break, and this ought to be the function of the nightly build. If the nightly is so critical to organizational progress that it simply must not be broken, then you need to give the devs something else.
The system should be made to serve its users, and not the other way around.
Not off-base at all. The rubber chicken shame totem would demotivate any team whose members might be assigned high-risk work. Too much stick, not enough carrot.
