Don’t just stand around saying somebody should do something: Be someone

On one of the frivolous mailing lists in the Windows project, somebody spotted some behavior that seemed pretty bad and filed a bug on it. The project was winding down, with fewer and fewer bugs being accepted by the release management team each day, so it was not entirely surprising that this particular bug was also rejected. News of this smackdown threw the mailing list into an fit of apoplexy.

Don't they realize how bad this bug is? Somebody should reactivate this bug.

Yeah, this is really serious. I don't think they understood the scope of the problem. Somebody should mark the bug for reconsideration.

Definitely. Someone should reactivate the bug and reassert the issue.

After about a half dozen of messages like this, I couldn't take it any longer.

I can't believe I'm reading this.

I decided to Be Someone. I reactivated the bug and included a justification.

Don't just stand around saying somebody should do something. Be that someone.

(And even though it's not relevant to the story, the bug was ultimately accepted by the release management team the second time around because all the discussion of the bug gave the bug representative more information with which to to argue why the bug should be fixed.)

Comments (22)
  1. Danny Moules says:

    I always like to think of that 'someone' as the super hero who flies down and solves all devs problems as soon as they shout for it loud enough. She, too, is resigned to exist only in fantasy like the rest of the super heroes people wish for.

    Presumably her costume would just be a nicely pressed suit.

  2. Adam Rosenfield says:

    This sounds eerily like yesterday's discussion.  In that case, Cheong ended up Being Someone:…/10116393.aspx

  3. Mike Mol says:

    Serves as anecdotal evidence for the business value of "frivolous" mailing lists, too.

  4. Bahbar says:

    @Danny Moules: and your point is well made. Raymond is indeed a super hero who flies down and solves all devs problems. The only problem is, he may get tired of it :D

    On a related note, Raymond, is the fantasy world on the other side of this airtight hatchway ?

  5. Roman Zenka says:

    If there was no arguing, the bug representative would not have more information! Being Someone right away would be counterproductive in this case!

  6. Anonymous Coward says:

    Raymond: shouldn't this post also be in the "The social skills of a thermonuclear device" category? ;-)

  7. Thorsten says:

    Consider the bystander effect in psychology:…/Bystander_effect

    It's very easy to moan. It's something entirely different to actually DO something about it.

  8. Ian Boyd says:

    Which is different from, "Someone should change how this behaves."  After yesterday of "rogue" features, someone learns that the proper way to change a behavior is to argue for it, convince others it's needed, find offsets in other features to schedule localization, documentation and testing, find enough pros to outweigh the cons.

    Or i can decide i'm too exhausted to do all that again. It would have been a good change, but if i have to argue every step of the way: i give up, and let the system be design-by-committee.

  9. Chris B says:

    (Apologies if I double post, the post button brought me back here without any indication of success or failure.)

    Strangely, this reminds me of a restaurant I worked at while in college that served complementary dinner rolls to every table. On busy nights, many servers would loudly (and profanely) gripe about how there was no bread ready, and none was on the way.  The thing that always struck me about it, was that those who griped the loudest were usually the last to actually do something to solve the problem (like putting bread in the oven, or ask for help).  Back then, I would usually take on the "be somebody" role and take care of it. Looking back now, I wonder if by doing so, I actually perpetuated the problem.

  10. s/Somebody/Somebody with enough cred to get this thing through triage/

  11. Joshua says:

    Unfortunately, this is the downside of banning rogue features and easter eggs.

  12. Simon says:

    Yeah, you see this kind of thing a lot in the open-source world. Lots of bugzilla noise from people demanding the problem be fixed, not so much from people offering to help fix it.

  13. Christian says:

    Reminds me of "They call it the politician's fallacy:

    1.Something must be done.

    2.This is something.

    3.Therefore, we must do it."


  14. Trylks says:

    It's still pretty bad when you have to argue with people for them to do their job properly and informing them of their mistakes is not enough, no matter who you or they are.

  15. Jolyon Smith says:

    @Roman Zenka – I thought the same thing.

    If somebody had been somebody sooner, it would most likely have just been closed off again.  This would have added weight to the closing off argument: "It's been closed twice already without being accepted for fixing…".

    In this case, the preceding INaction was arguably necessary to the eventual success of the ACtion.

  16. Joshua Ganes says:

    Sometimes these types of discussions are a way of verifying support for your position. Sure, *I* think it's important, but what does the rest of the team feel? If other people agree, I will gladly be "someone".

  17. Cheong says:

    Btw, I think it follows "Poisson law of small numbers". So it's somehow unfair to say there's too few "someone" exist.

    If there is someone already, chances are "something" is already done so you won't see people moaning. People's moaning, is easier to get into your radar than works silently be done.

    Also, there's also some people who need to gather opinion from other people, verify that others also need the action, before deciding to perform the action. So arguably, I think "keep moaning and something could be done" is true in certain level.

  18. jason says:

    "with which to to argue".

    duplicate word "to".  delete one of them.

  19. Miral says:

    @Simon: That's probably because quite a lot of code (open-source or not) is *scary* bad (or at least difficult to understand).

    Also, issues of "ownership" sometimes get in the way.  I can think of a few cases where something was identified as a problem, and someone even provided a patch to fix the problem (without negative consequences), but the maintainer refused to integrate it because "it wasn't important enough to write my own fix".

  20. David Walker says:

    Right, if something must be done, and this is something, then we must do this.  But is this the right thing to do?  :-)

  21. benjamin says:

    I think what's left unsaid in discussions like these is the fact that people don't want to be 'Someone' because that person will inevitably either become a scapegoat when things go wrong or, perhaps even worse, speaking up just means you'll end up getting the problem dumped in your lap to work on all by yourself.

    Of course, in cases like these I like to turn to the knowledge I've gained from Mr. T: "Be Somebody, or Be Somebody's Fool."

  22. 640k says:

    These kind of discussions is usually a result of "politics" in the development environment. It's a signal of a bad work place. To be "somebody" WITHOUT making a scene is a guaranteed FAIL in these circimstances.

    The developers complaining isn't really complaining about any specific bug or missing feature, they're complaining about how the ignorant management prioritize.

Comments are closed.

Skip to main content