- 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
Did Matt really expect any other outcome? That's TRWTF
Admin
Reminds me of Spinal Tap. "Why not just make 10 louder?" "These go to 11."
Admin
Continuing from the article:
By quitting that afternoon. And having a second, albeit individual, release party. Release from PHB-driven Dev Hell.
Admin
There's no problem that can't be handled by another layer of abstraction: create a QA process to the QA process, split the ticket into sub-tickets in QA', report sub-tickets to QA', which in turn closes the QA ticket… After all, it's programming and algorithms! ;-)
Admin
I don't work there any more.
Admin
It's not only the KPI, it's that the people were committed to sticking to the KPIs. We can't tell the reason, but performance reports and bonuses would be my guess.
Admin
Yep, I left.
Admin
It just needs two ticket systems - the ticket system for manglement and the real ticket system.
Admin
I worked at a 3-letter company in the 1980s where we were supposed to release OS code with <= 1 defect per 10K lines of code (the OS products in question were 300 - 600KLOC at the time). We did our best to be honest and NOT create bundled bugs like this example - but I can't remember a single time where we didn't have to get a corporate waiver to release with a higher defect density - more typically about 1.8 - 2.5 / 10KLOC. [Note that I am distinctly NOT making a value judgment about the usefulness of defects/KLOC; that was the metric we had at the time. The OS was written in assembly language; make of that what you will.]
Admin
Sounds similar how stuff is done where I work... they consider work done to be "closed tickets" so there's all this nonsense because nobody has the balls to explain to the business how it should work, management just behaves like we work FOR them instead of being partners with them. Incredibly frustrating to begin with, but it's more frustrating how many people in development act like the other departments are full of dragons or trolls or something that will eat you if you try to talk to them like human beings and explain things.
Admin
It's pretty normal to get this reaction to raising bugs/issues where the higher management can see the numbers. Keeping two sets of bugs is a bit dodgy; a better option is to have a flag to distinguish a bug as being 'public', then have it refer to a layer of non-public blockers which are sold as the plan to resolve the main issue.
Admin
Two things:
"These are post release bugs. Which means we released software with bugs in it." - That is completely normal today, to be expected, and the only way it actually "works". Everyone does it that way.
And:
"But this dashboard doesn't track bugs, it tracks tickets." - When your manglement decisions are based on traffic lights, i. e., on two or three colors, simplify everything. Even your product. That might help. Make it work as expected ("green light"), or not work at all ("red light"); bonus points for buggy software ("yellow light"), which seems to be today's "modern" standard and expectation.
And finally - three, three things:
"Matt admitted defeat and fixed the ticket the hard way." - By leaving the company as soon as possible.
Really, why do programmers still (!) seem to think it is okay to work that way? And how can companies doing this be considered "businessing successfully"? Imagine it was a hospital - patients would just die! "But this dashboard tracks dismissions, not survivors! See? No red lights. See?"
Fix that problem first, and everything else will follow.
Admin
Should have just asked him to open those as subtasks. That's what the feature is for.
Admin
I expected the bug on Tuesday to be: "Can't log any tickets..."
Admin
"I cannot do anything without a ticket" is the most stupid and destructive statement you can here and pretty much sums up that the company is completely bugged on a fundamental level - which to no surprise can be seen in their software as well.
Admin
Tickets for development is kinda stupid anyway. A ticketing system is for your Helpdesk crap. now, yes, for development you see stories/bugs/etc. but that is something for development eyes only. It shouldn't be linked to some kind of generic helpdesk app so Karen in Finance can see what development is doing.
Admin
"Shall I tell the CEO that you and QA are lying to him?"
Admin
"You're getting bugs, you're getting bugs. You can't create more tickets. What can you do? So what we do is, whenever we have bugs and we need that extra room for the release, you know what we do?"
"You put them under one ticket."
"One, exactly. So it's a one-ticket release. Almost perfect."
"Why don't you make the ticket limit higher and track the tickets accurately?"
"These releases have one."
Admin
Because there's a door for them to walk out of if they don't like it, and finding another job is not guaranteed. Duh.
Admin
So the OS was written in asm and you had a requirement for 1 bug per kloc... you have direct access to nops in asm, I can't see what the problem is, you can get to 1 bug per anything-you-want.
Admin
Admin
The only way to fight stupid policies is by creating policies.
One option is to create a policy that only one bug gets fixed per ticket, no more. If there are more, only the first bug listed gets fixed.
Admin
I can only speak from my perspective here. But my answer would be because I don't care and I should not care. If a patient dies in a hospital that's a tragedy. If software has bugs that's a ticket. Big difference. Nobody should be loosing sleep over bugs.
And if this sort of thing is the worst annoyance you get in an otherwise decent job why complain? After all, it's just a job. I ain't married to it. Even if the company goes under because of poor management that's not my problem. In this market (and it's been this way for decades) a good software engineer can always find a new and better job over night. And that does not look like it's going to change any time soon.
So honestly jobs are something you pick up and stay until it stops being comfortable or you drain them dry. And than you move on. Kind of like marriage actually.
Honestly, I would not have pushed things any further than asking the first QA guy I came across for an explanation at the water cooler. And even that just out of curiosity. I would definitively not have complained to management.
Admin
I used also always say "hey nobody will die because we have bugs" ... Except, then I spent a year working as a dev on the logistics systems for a hospital chain. If the right organs (for example) dont get to the right patient withon a defined time, they are unusable and maybe someone DOES die. I did think about that a bit differently in that job! Aviation, military, vehicles - all other possible "people can die because of a bug" domains. it depends, it depends...
Admin
True enough. But as a general rule the majority of software developers know if their software is going into critical applications such as those or not in advance and can adjust their attitude accordingly. Personally I always made a point of avoiding jobs that require me to bear such responsibility.
Not that it really matters all that much either way as the odds are vanishingly rare that even if the worst does happen and people die the fallout from that is going to actually reach the developers. At worst the company may get sued into the ground and I might need to find a new job.
But it still gave me some piece of mind to know that the hospital I might be treated at or the airplane I might be flying on does not have software written by yours truly.
I am good, bloody good even. But I don't want to be the victim of ironic suicide. :)
Admin
You forgot radiation therapy machines, ones that might be called Therac-25.
Admin
Did anyone ever get punished for that anyway?
Admin
It is precisely the attitude that "quality is immaterial. As long as I can get away with shoddy or selfish work, it's OK. I'm just in it for me." that leads to nasty management defrauding the employees and the shareholders, that leads to slacker I-don't-give-a-shit workers, and the general enshittification of society.
You (any you) are either part of the solution or you're part of the problem. Lead by example.
Admin
There is a big difference between not caring about quality at all and being realistic about your position in reality. Employment is not friendship, it is not love or belonging. Your job is not your life or your family. And it is not about caring or emotions of any kind.
Employment is a trade transaction.
When you are an employee you are selling your labor and time in exchange for money and benefits. Therefore it is your contractual obligation to make sure the employer gets what they pay for which includes meeting what ever standard of quality they require. No more and no less. Equally it is the employers contractual obligation to provide the pay and benefits written in your contract. Again, no more and no less. And as long as both sides deliver what is contractually demanded everyone is happy.
But that is where the relationship ends. Neither side gives a shit about the other beyond that nor are they supposed to.
It is no different than any other kind of trading.
When you go to the grocery store all they care about is that you pay them and all you care about is that they have the goods you want and that they aren't spoiled. If you stop coming one day they will just find new customers. And if they shut down one day you'll just find another store.
It's that simple.
Admin
"But I don't want to be the victim of ironic suicide. :) " yeah, excellent point!
Admin
Exactly this. A ticket system should be completely separate from a source control, issue/bug, commit tracker. If a bug is found via the former, an issue can be opened by a dev in the latter side and then discussed and worked on by the appropriate devs/team, after which a response can made to the originating ticket.