• LCrawford (unregistered)

    Tickets frist, then work!

  • Brian Boorman (google)

    And then Matt was let go because his code contained so many bugs in the first place.

  • Kevin (unregistered)

    This speaks to a bad management/development culture. Quality is a team effort; bad quality isn’t any single person/tean’s fault, assuming they did the work they said they would.

  • (nodebb)

    And then management shot the messenger because clearly Matt knew this and went along with it.

  • (nodebb)

    Be careful what you measure, for that is exactly what you will get.

  • Andrew (unregistered)

    Is this story incomplete? I think there is more to this story, perhaps someone being fired?

  • Dave (unregistered)

    Just assign the ticket back to them with a note saying 'these are separate issues and require separate tickets'. Their move. Either they do as asked, or they dont, and then they haven't submitted the necessary tickets.

  • Tim (unregistered) in reply to Andrew

    Or Matt being beaten badly in a dark alley on his way home by the entire test team...

  • D-Coder (unregistered) in reply to Tim

    I hate it when that happens.

  • (nodebb)

    /me bans defect tickets, problem solved.

  • (nodebb)

    Some people use web forums as issue trackers, and delete all “issues” from them once they decide they're not going to work on them any more, whether that's because the issue is fixed, no longer relevant, a figment of the user's imagination, makes management depressed, or because they've decided that they hate the people posting the issue and therefore nothing they report is possibly valid.

    Who might I be thinking of here…?

  • Drone (unregistered)

    Clearly the answer here is to introduce a small bug into the defect tracking system. With no working defect system, no new tickets can be issued. Without a ticket, the defect system cannot be fixed. All teams now enjoy a zero defect rate. Everybody wins!

  • (nodebb)

    TRWTF is the absence of any defect tickets in all prior releases did not raise any flags. ALL software has defects, even the most basic things like those programs to count from 1 to 2345 by 67s we write in CS-101.

  • Developer Dude (google) in reply to Kevin

    Exactly, if a defect is the "fault" of anyone, it would usually be the developer.

    However, there are often defects in requirements, design and sometimes in QA (especially testing) if they missed testing (or didn't test correctly) some specific defect or feature.

    There is no way testing can test every feature completely. The job of QA is to prioritize their resources such that they have a higher probability of finding the worst defects before they go out into the hands of the user.

    But yes, quality is the job of everybody.

  • CodePosse (unregistered) in reply to LCrawford

    logging defect; typo for first spelled as frist. 3 story points.

  • CodePosse (unregistered)

    roll-up tickets ftw! ftw means f*** the weekend, because you just lost yours to catch up

  • CodePosse (unregistered) in reply to Drone

    maybe not the customers...

  • TooLazyToSignUp (unregistered) in reply to Bananafish

    all software has defects.

    Not so sure about that statement: https://www.youtube.com/watch?v=3aFeGGyi19A

    Assuming the formal verification software doesn't have defects.

  • (nodebb)

    When ever you invent some number to measure performance, people will optimize the number, not the performance.

  • that other guy (unregistered) in reply to CodePosse

    Hi, you must be new here.

  • Regurgitated rubbish (unregistered) in reply to KattMan

    Be careful what you measure, for that is exactly what you will get.

    KPI gaming is the best sport in the world.

    I was working for a bank in their risk department, where KPI was measured in issues raised (more is good) and issues (closed again, more is good). Bad is issues that took a long time to be resolved. So the obvious solution is on the last day of the month to close all outstanding issues, and re-open them the following day. We found 10 issues and closed 10 issues! Woot!

    Another time was working for a Japanese car maker who were very big on 'just in time' stock management. The KPI was based on holding one months worth of stock, so if you sold one a month then having two on hand was bad, three was really bad. However, stock in transit didn't count, and as there were multiple warehouses...

  • (nodebb) in reply to Regurgitated rubbish

    I'm reminded of some past occasions (not super common) where we figured (a) something would take several sprints to finish and (b) it wasn't yet obvious which parts would need enough work to be worth breaking out as separate issues, so each sprint we created and closed an issue amounting to "do a sprint's worth of work on it" until it progressed far enough that (b) changed.

  • Oliver Jones (google)

    When I was a software company exec we banned the use of metrics from our ticket system in performance reviews for people or departments.

    Those metrics are just too easy to game. Gaming them takes away a very good tool for staying on top of workflow and quality.

  • (nodebb)

    @emurphy That strikes me as WTFing around overly rigid sprint planning/scrum dogma. In a sane world, you'd be able to just add the next N subtasks for the feature. Then if mid-sprint in turned out they were all tiny would just pull more in from the backlog as needed, or if they all turned out to be huge accept that several would roll over into the next sprint.

  • Neveralull (unregistered)

    We get story points for new features, none for fixing bugs. And they wonder why I deliver new features each Sprint while my bugs are not worked on.

  • Little Bobby Tables (unregistered)

    OP here.

    An update: the issue has raised its ugly head again. We are in argument with the project manager, who is insistent on the multi-issue bug reports, because it makes the team "look good". Voices are raised and tempers are incandescent. I'm going to have to get the popcorn in, because this has gone once again to top level management and it's going to be entertaining.

Leave a comment on “Keeping Up Appearances”

Log In or post as a guest

Replying to comment #:

« Return to Article