- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
Tickets frist, then work!
Admin
And then Matt was let go because his code contained so many bugs in the first place.
Admin
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.
Admin
And then management shot the messenger because clearly Matt knew this and went along with it.
Admin
Be careful what you measure, for that is exactly what you will get.
Admin
Is this story incomplete? I think there is more to this story, perhaps someone being fired?
Admin
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.
Admin
Or Matt being beaten badly in a dark alley on his way home by the entire test team...
Admin
I hate it when that happens.
Admin
/me bans defect tickets, problem solved.
Admin
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…?
Admin
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!
Admin
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.
Admin
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.
Admin
logging defect; typo for first spelled as frist. 3 story points.
Admin
roll-up tickets ftw! ftw means f*** the weekend, because you just lost yours to catch up
Admin
maybe not the customers...
Admin
Not so sure about that statement: https://www.youtube.com/watch?v=3aFeGGyi19A
Assuming the formal verification software doesn't have defects.
Admin
When ever you invent some number to measure performance, people will optimize the number, not the performance.
Admin
Hi, you must be new here.
Admin
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...
Admin
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.
Admin
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.
Admin
@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.
Admin
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.
Admin
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.