SoylentNews is people
SoylentNews
Some of the worst moments of my day happen when I get an email or a call from a customer who has found a bug in my released software product. It's even worse when I'm on site for training and they find the bugs there. No matter how rigorously I QA/test, it seems inevitable that a customer will find a way to break the software within the first few minutes of using it.
The key, then, is how do you respond? David Cummings has some thoughts on how to handle these scenarios. What's interesting is that there's an idea that maybe not all bugs need to be fixed, at least not right away. This is counter to The Joel Test where Joel Spolsky feels you should fix all known bugs right away, even before adding new features. Does this make sense? Is it more important to get new features out the door sometimes than to have as bug-free software as possible?
I'm reminded of this story, where adding a feature before fixing bugs actually saved the project.
(Score: 3, Insightful) by halcyon1234 on Sunday October 12 2014, @03:38AM
Really? In 2014? We need to ask how?
Dump the bug in a tracker. Schedule it to be fixed. Maybe add the customer to a mailing list to let them know when it's fixed.
If you're a professional, is there any other way?
Original Submission [thedailywtf.com]
(Score: 2) by microtodd on Sunday October 12 2014, @01:22PM
I guess I meant respond not necessarily in talking to the customer, but in how do you insert this into your development process. Do you just add it to your backlog/bugzilla? What priority does it get? Does it automatically get added to the next sprint/patch, even if its minor, just because it had visibility and you want to show your customer you care? Or do you maybe even do an emergency patch/fix circumventing your current sprint?
There are times that we literally put a sprint on hold, fixed a minor bug, ran the QC cycle in 1 day, then had the patch ready for the customer in 2-3 days. For a minor bug. But, later on a director at the company told me he appreciated us responding so quickly.
And I'm always curious to see how other developers think.
(Score: 2) by RaffArundel on Monday October 13 2014, @03:19PM
This.
I just wanted to add the zero step, implied by step 1 but often missed, because it is here that things go sideways in my experience:
0. Take a deep breath. You are not your code. Accept there will be problems, and the person reporting it isn't attacking YOU even if it looks like they are.
Even if the report is written like "flamebait" follow the rule. Someone cared enough to report an issue from their POV, even if it is just to vent. Someone could be trolling you, but before you make that snap judgement make sure. Doesn't matter if it is an actual code bug, a design decision, a required limitation of your platform, or simply a use-case you have no intention of supporting. Never respond in kind to this type of trolling - even a terse "we will look into it" (but step 1 is much better) should be used since either the troll failed to get a rise and will move on or when you have to shut the conversation down you can do it from the high ground.
Slightly OT: there are two things I have say to almost every new CS grad - first, you gotta work as a team. Code clarity and documentation is actually important around here. Maybe not for you (but it is, you just need the experience to understand that) but for the rest of us who need to support you. Second, you are not your code. I'm going to correct you when you use the wrong pattern, deviate from company standards (no matter how silly they are), or find that new hip library you really really really want to use instead of that old vetted one. If you take it personally, you are going to have a really hard time getting things done.