Stories
Slash Boxes
Comments

SoylentNews is people

posted by martyb on Saturday October 11 2014, @11:23PM   Printer-friendly
from the arachnephobia dept.

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.

This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 1, Interesting) by Anonymous Coward on Saturday October 11 2014, @11:31PM

    by Anonymous Coward on Saturday October 11 2014, @11:31PM (#104896)

    I just saw this comment [soylentnews.org] about a potential password issue with SN's code! Can anyone confirm or deny it?

    • (Score: 0) by Anonymous Coward on Sunday October 12 2014, @12:11AM

      by Anonymous Coward on Sunday October 12 2014, @12:11AM (#104906)
      • (Score: 5, Informative) by paulej72 on Sunday October 12 2014, @01:14AM

        by paulej72 (58) on Sunday October 12 2014, @01:14AM (#104921) Journal

        The bug has been squashed and deployed to production, and I am grateful that the Community has brought it to our attention. Luckily it was not something that we wrote, rather something that we inherited. If anyone finds shit like this again, please let us know and we will fix it. I for one welcome our GitHub-reading bug-finding overlords.

        --
        Team Leader for SN Development
        • (Score: 0) by Anonymous Coward on Sunday October 12 2014, @01:57AM

          by Anonymous Coward on Sunday October 12 2014, @01:57AM (#104940)

          Thank you for fixing it within minutes of it being reported. This is what really separates SN from the other similar sites: SN is about getting stuff done right, and fixing it right away if it isn't done right. This is totally the opposite from the Slashdot Approach, like we saw with the Beta site, where they basically forced open our mouths and shit right down our throats into our stomaches.

        • (Score: 3, Insightful) by Wootery on Sunday October 12 2014, @01:27PM

          by Wootery (2341) on Sunday October 12 2014, @01:27PM (#105045)

          Luckily

          Not really, no.

  • (Score: 4, Informative) by fadrian on Saturday October 11 2014, @11:47PM

    by fadrian (3194) on Saturday October 11 2014, @11:47PM (#104899) Homepage

    Joel is often too simplistic (you have to be for a blog).

    Not all bugs can be fixed immediately. Some are too deep or architecturally based to be fixed "immediately". Some are vague - should it work this way or that? We chose this, turns out the customers wanted that. Is that a bug? Seems like it to the customer, even if it's technically "correct". But maybe you want to make that an option - should that "new feature" be put in immediately?

    Bugs on users main usage paths need to be fixed and they often need immediate patch-level response. For those things that aren't on the main path or are cosmetic, well, they should be fixed before the next release. Or, if you're agile, fix the functional bugs in the code you're writing this sprint during the sprint. All others become prioritized with user stories.

    Is it really more difficult than this? Well, other than finding people to fix all of them?

    Besides, you should be looking at ways of preventing bugs rather than asking questions about when to fix them.

    --
    That is all.
    • (Score: 2) by Adamsjas on Sunday October 12 2014, @12:05AM

      by Adamsjas (4507) on Sunday October 12 2014, @12:05AM (#104905)

      I agree, there is a good case for Triage here.

      Show stopper bugs have to be fixed right away.
      Annoyance bugs, that can be worked around can wait for later.
      Things you can't work around probably have to get fixed soon
      Spelling and silly stuff like that can wait till the next release.

      Like everything else in life, there is a middle ground.

      • (Score: 3, Informative) by c0lo on Sunday October 12 2014, @01:19AM

        by c0lo (156) Subscriber Badge on Sunday October 12 2014, @01:19AM (#104925) Journal

        Things you can't work around probably have to get fixed soon

        Anecdote: automated regression suits stopped early by an elusive bug (was happening due to race conditions - automation does allow you greater execution speed). Of course, under the management's pressure to add for more features, the devs triaged it as low priority - more so as they couldn't repro manually; also low priority was set for adding more comprehensive logging capabilities as they didn't add value to the customer (and who has the time for the needle in 100MB of logs?)

        The results: even smoke tests needed to go manually, thus reducing the coverage for higher level functionality. The product was released ("on time to be on the shelf on Black Friday"), with heaps of bugs. Funny, that bug the devs couldn't be bothered put more effort in reproducing surfaced frequent enough in the customer support, but by then was buried under heaps of features - thus would surface in quite varied context mostly unrelated with the features. After 10 months of development, there was another 3 months in which not only dev and QA were bound to an endless patch release cycle, but the customer support skyrocketed and the users' opinion started to nullify the marketing money being poured in.
        (the product doesn't exists anymore, the company barely registers as relevant).

        TLDR: I'm with Joel on this one - using anything build on crappy ground is a matter of betting on the life of your product; it may work once, but not on the long run.

        --
        https://www.youtube.com/watch?v=aoFiw2jMy-0 https://soylentnews.org/~MichaelDavidCrawford
        • (Score: 0) by Anonymous Coward on Sunday October 12 2014, @01:03PM

          by Anonymous Coward on Sunday October 12 2014, @01:03PM (#105041)

          That sounds like Firefox.

      • (Score: 5, Insightful) by paulej72 on Sunday October 12 2014, @01:22AM

        by paulej72 (58) on Sunday October 12 2014, @01:22AM (#104927) Journal

        For the few of us working on Slashcode, we try to do just that. There is so much to do and so few of us, it may seem to the users that we are not listening. For the most part we do listen, we just can't fix everything in a short time. Plus some of the issues are a bitch to track down as they are intermittent bugs, or are specific to situations that we devs do not have easy access to. So feel free to bitch at us if you like, we can take it, but understand we are trying.

        --
        Team Leader for SN Development
        • (Score: 0) by Anonymous Coward on Sunday October 12 2014, @01:53AM

          by Anonymous Coward on Sunday October 12 2014, @01:53AM (#104939)

          We know you're working hard, and we appreciate everything you do for us. We know that Perl code, especially code you didn't write yourself, is a real bitch to work with. We don't hold it against you!

        • (Score: 1) by khedoros on Sunday October 12 2014, @06:58AM

          by khedoros (2921) on Sunday October 12 2014, @06:58AM (#104991)
          Oof, I've written messages very close to that to explain to customers why it can take a while to analyze the GBs of logs that they just sent, find the bug that the logs reflect, engineer a fix, and get them a binary to test. My employer is large enough to have a massive customer support organization, so by the time a customer service request gets escalated to the point that a developer gets involved, they're usually pretty testy (but at least I've usually got a support technician acting as an interface between me and the customer).
        • (Score: 0) by Anonymous Coward on Sunday October 12 2014, @08:23AM

          by Anonymous Coward on Sunday October 12 2014, @08:23AM (#104999)

          Part of what makes SN such a great experience are devs who actually listen & react to our concerns. Thank you a thousand times.

          • (Score: 0) by Anonymous Coward on Sunday October 12 2014, @06:32PM

            by Anonymous Coward on Sunday October 12 2014, @06:32PM (#105171)

            He had this problem fixed within minutes after it was reported! That's astoundingly good customer service! Just compare it to how Slashdot handles things. The Slashdot Beta is still around, so many months after users reported that it was irreparably buggy and needed to be thrown away. That's bad customer service!

    • (Score: 2) by mcgrew on Sunday October 12 2014, @11:32AM

      by mcgrew (701) <publish@mcgrewbooks.com> on Sunday October 12 2014, @11:32AM (#105027) Homepage Journal

      Joel is often too simplistic (you have to be for a blog).

      Why? That makes no sense to me.

      Not all bugs can be fixed immediately. Some are too deep or architecturally based to be fixed "immediately".

      Like GM's ignition keys? Bugs are product defects. Bugs are a sign of shoddy work.

      Some are vague - should it work this way or that? We chose this, turns out the customers wanted that. Is that a bug?

      No. A bug is when your code doesn't act as designed. When your customers don't like your design, that's a design defect.

      --
      mcgrewbooks.com mcgrew.info nooze.org
      • (Score: 2) by microtodd on Sunday October 12 2014, @01:27PM

        by microtodd (1866) on Sunday October 12 2014, @01:27PM (#105046) Homepage Journal

        No. A bug is when your code doesn't act as designed. When your customers don't like your design, that's a design defect.

        Interesting. I've had this argument a lot with engineers. Does a design defect count as a "bug"? Some people insist yes, its a bug in the requirements or a bug in the design. Other say no. This is a tough one, especially when talking with customers.

        • (Score: 2) by BasilBrush on Sunday October 12 2014, @06:48PM

          by BasilBrush (3994) on Sunday October 12 2014, @06:48PM (#105178)

          Rather than have a semantic debate on the limits of what's a bug, just stop talking about bugs and talk about defects instead. Track defects not bugs. Then design or documentation problems are handled no differently from defects in code.

          --
          Hurrah! Quoting works now!
  • (Score: 4, Funny) by LookIntoTheFuture on Sunday October 12 2014, @12:00AM

    by LookIntoTheFuture (462) on Sunday October 12 2014, @12:00AM (#104903)

    The key, then, is how do you respond?

    By saying "That's not a bug, it's a feature!" Followed by violence.

    • (Score: 1) by Ethanol-fueled on Sunday October 12 2014, @01:00AM

      by Ethanol-fueled (2792) on Sunday October 12 2014, @01:00AM (#104917) Homepage

      I dealt with this at work fairly recently, so here's my take:

      Background -- we have a robotic carriage thingy that is controlled by a software program which does only one routine, and if you want to execute your own routine, you have to sit at the workstation and babysit it, manually pressing buttons. I wrote a control program to allow people to define their own routines and run them in a loop indefinitely if they wanted to. The program was a hit with engineers. At least until recently, when a junior engineer e-mailed me slamming my program, bringing up all these edge-cases in which he said the program didn't behave intuitively.

      I replied in a nice way, "Listen, bitchboy, I'm a lowly technician who did it to make all of our lives easier. You didn't write it, and neither did any of your devoid-of-common-sense engineer buddies. If this is so simple, then why didn't manufacturing engineering make something like this a long time ago when there was obvious demand? Here's where the project is in the repo, if you want all of your cute features you're more than welcome to code them yourself."

      But then again, this is a place that's totally fucked and nobody cares. I submitted a bugzilla entry on a bug in another piece of software that wasn't detecting a certain version of firmware. The manufacturing engineer (who doesn't know English for shit) asked me about it, but I decided to fix it myself since it was literally 5 minutes of work adding a few entries in the code. I fixed it, checked it again for errors or introduced bugs, then e-mailed the fixed source file to the engineer (since I don't have write access to projects other than mine, only read access) and copied his boss basically saying, "I did your job for you and fixed the bug. Go ahead and SVN-update the file."

      It's still months later and the source still hasn't been updated, and for some reason I don't think it ever will be. And kind of offtopic, but SVN is a horrendously difficult and counterintuitive piece of shit. Do you all agree, or am I just a pussy?

      • (Score: 0) by Anonymous Coward on Sunday October 12 2014, @01:15AM

        by Anonymous Coward on Sunday October 12 2014, @01:15AM (#104922)

        What do you find confusing about SVN?

        It's more intuitive than git in many ways. And it doesn't have the Rubyist and JavaScripter baggage that git has. You can't google anything about git without running into some self-righteous Ruby slobs blabbering on about rebasing or some JavaScripters being amazed by the concept of branching.

        • (Score: 2) by tibman on Sunday October 12 2014, @07:34AM

          by tibman (134) Subscriber Badge on Sunday October 12 2014, @07:34AM (#104995)

          Git branching IS nicer than TFS, for sure. Git and SVN are similar in that it is copy on write. Unchanged branch code just points to its parent.

          --
          SN won't survive on lurkers alone. Write comments.
      • (Score: 2) by black6host on Sunday October 12 2014, @01:15AM

        by black6host (3827) on Sunday October 12 2014, @01:15AM (#104923) Journal

        Do you all agree, or am I just a pussy?

        This doesn't have to be a question of the pick A or pick B variety with only one answer. Both could be true. But not knowing you I'll reserve judgement on the latter. :) (j/k with you...)

      • (Score: 2) by c0lo on Sunday October 12 2014, @01:45AM

        by c0lo (156) Subscriber Badge on Sunday October 12 2014, @01:45AM (#104936) Journal

        "Listen, bitchboy, I'm a lowly technician who did it to make all of our lives easier. You didn't write it, and neither did any of your devoid-of-common-sense engineer buddies.[...]
        Do you all agree, or am I just a pussy?

        The jury may still be out on the pussy thing, but blaming all the engineers buddies for the rant of one clearly demonstrates that, at least occasionally, you can be a hypersensitive dick.

        Background -- we have a robotic carriage thingy that is controlled by a software program which does only one routine, and if you want to execute your own routine, you have to sit at the workstation and babysit it, manually pressing buttons. I wrote a control program to allow people to define their own routines and run them in a loop indefinitely if they wanted to.

        OT (if you ignore the "Reaction" word in the title) and tangent to the above: I discovered last Friday SpaceChem [zachtronics.com] - addictive (for me at least).

        --
        https://www.youtube.com/watch?v=aoFiw2jMy-0 https://soylentnews.org/~MichaelDavidCrawford
        • (Score: 1) by Ethanol-fueled on Sunday October 12 2014, @02:15AM

          by Ethanol-fueled (2792) on Sunday October 12 2014, @02:15AM (#104944) Homepage

          " The jury may still be out on the pussy thing, but blaming all the engineers buddies for the rant of one clearly demonstrates that, at least occasionally, you can be a hypersensitive dick. "

          You're not taking into account that I am familiar with the corporate culture and work personally with those engineers face-to-face on a near-daily basis. In spite of the company's faults it is rated highly on work/life balance, which means that engineers get to fuck off all day and leave early, and get monthly barbecues for shipping buggy products years late.

          But yeah, I am a dick and you can suck my dick.

          You gotta be a dick when you work for a company full of dicks, where rudeness and abusive behavior is not only tolerated, but tacitly encouraged by management. It's a shark-tank in there, man, and if you don't bite back you're ground up like chum and ejected out the asshole orifice. I've loudly chewed out my boss' boss to his face, in his own office (and all of the other management listening), without a damn thing happening to me. Even won a concession out of it. Even the head of HR (who I can speak with on an informal basis) shuts the door, draws the blinds, and rests her head in her hands lamenting, " This place is so dysfunctional. I'm so busy dealing with conflict that I cannot implement anything that would actually add value. "

          • (Score: 2) by c0lo on Sunday October 12 2014, @03:12AM

            by c0lo (156) Subscriber Badge on Sunday October 12 2014, @03:12AM (#104951) Journal

            But yeah, I am a dick

            Get off the high horse; the fact that you persist in working in the same full-of-dicks company shows that you may have your pussy side: that part of you that accepts being fucked.

            and you can suck my dick.

            (choosing to take you impersonally here) My opinion? The dick is to valuable to me to stick into blinking-eyed shits. Either we can do a job together, or otherwise it's a waste of time and it doesn't matter who is right.

            I've loudly chewed out my boss' boss to his face, in his own office (and all of the other management listening), without a damn thing happening to me. Even won a concession out of it. Even the head of HR (who I can speak with on an informal basis) shuts the door, draws the blinds, and rests her head in her hands lamenting, " This place is so dysfunctional.

            As I said, a waste of time. Life's short... but then again, if you occasionally like fucking lowly creatures (no matter their hierarchy level), while most of the time being their whore to be orgiastically gang-banged - together with the other common-sensical mates - and paid peanuts ... whatever floats your boat.

            I admit, I played the "corporate whore" myself in the past - knowing very well that I need to survive until getting to something better. Fortunately, I could afford to get out of the coprorate games soon enough.

            --
            https://www.youtube.com/watch?v=aoFiw2jMy-0 https://soylentnews.org/~MichaelDavidCrawford
            • (Score: 2) by cafebabe on Sunday October 12 2014, @11:25PM

              by cafebabe (894) on Sunday October 12 2014, @11:25PM (#105332) Journal

              full-of-dicks company [...] pussy side [...] being fucked.

              I've heard this kind of talk before. From Team America: World Police:-

              Gary Johnston: We're dicks! We're reckless, arrogant, stupid dicks. And the Film Actors Guild are pussies. And Kim Jong Il is an asshole. Pussies don't like dicks, because pussies get fucked by dicks. But dicks also fuck assholes: assholes that just want to shit on everything. Pussies may think they can deal with assholes their way. But the only thing that can fuck an asshole is a dick, with some balls. The problem with dicks is: they fuck too much or fuck when it isn't appropriateĀ - and it takes a pussy to show them that. But sometimes, pussies can be so full of shit that they become assholes themselves... because pussies are an inch and half away from ass holes. I don't know much about this crazy, crazy world, but I do know this: If you don't let us fuck this asshole, we're going to have our dicks and pussies all covered in shit!

              --
              1702845791×2
          • (Score: 0) by Anonymous Coward on Sunday October 12 2014, @03:22AM

            by Anonymous Coward on Sunday October 12 2014, @03:22AM (#104954)

            dick

            Compared to the other text in your comment, that word is big.

            Compared to the other text in your comment, that word is black.

            Big. Black. Dick.

            Are you trying to tell us something?

          • (Score: 2) by halcyon1234 on Sunday October 12 2014, @03:31AM

            by halcyon1234 (1082) on Sunday October 12 2014, @03:31AM (#104958)

            my dick.

            Pics or GTFO.

            --
            Original Submission [thedailywtf.com]
            • (Score: 0) by Anonymous Coward on Sunday October 12 2014, @03:44AM

              by Anonymous Coward on Sunday October 12 2014, @03:44AM (#104962)

              Why do you want to see pictures of another man's dink? Isn't that kind of queer?

              • (Score: 2) by Reziac on Sunday October 12 2014, @05:14AM

                by Reziac (2489) on Sunday October 12 2014, @05:14AM (#104978) Homepage

                Proof of concept.

                --
                And there is no Alkibiades to come back and save us from ourselves.
  • (Score: 3, Insightful) by paulej72 on Sunday October 12 2014, @01:16AM

    by paulej72 (58) on Sunday October 12 2014, @01:16AM (#104924) Journal

    Do I need to say more? PulseAudio, there I said it.

    --
    Team Leader for SN Development
    • (Score: 0) by Anonymous Coward on Sunday October 12 2014, @01:30AM

      by Anonymous Coward on Sunday October 12 2014, @01:30AM (#104930)

      Don't forget Avahi and kdbus.

    • (Score: 3, Insightful) by E_NOENT on Sunday October 12 2014, @01:30AM

      by E_NOENT (630) on Sunday October 12 2014, @01:30AM (#104931) Journal

      PulseAudio sucks, but it's only a foreshadowing of the circus that is systemd.

      I've been sitting in #sytsemd on freenode for the past few days. Lots of people showing up with problems, and the fix always seems to be "Oh, you're on 209? Upgrade to the last version" or similar. It sounds like the team is still duct-taping stuff together. Glad to know someone at Red Hat just prophesied that this was the One True Way.

      Fun times for all.

      --
      I'm not in the business... I *am* the business.
      • (Score: 0) by Anonymous Coward on Sunday October 12 2014, @01:51AM

        by Anonymous Coward on Sunday October 12 2014, @01:51AM (#104938)

        I never expected the Debian project to last forever. But I also never expected it to do so much in such a short period of time to totally extinguish and annihilate itself.

        How can they be adopting something that's just so awful? When I read about the problems with systemd [boycottsystemd.org], I just don't see how they can be solved or fixed. They are inherently part of its broken philosophy.

        2015 is going to be an annus horribilis [wikipedia.org] for the entire Linux community. I think we're going to see the Debian project splinter and wither. Slackware will see some uptake, but it's really far behind the times in so many ways. Debian users are flocking to FreeBSD as a result.

        Systemd will simultaneously be the worst thing that has ever happened to Linux, while at the same time being the best thing that has ever happened to the FreeBSD project.

        I'm surprised that Richard Stallman hasn't spoken out more against systemd. He has a lot to lose because of it. Systemd isn't just driving people away from Linux. It's driving them away from the GNU software stack, and it's driving them away from the GPL/LGPL/AGPL.

        FreeBSD is going to see a resurgence the likes of which it hasn't seen since the mid 1990s, all thanks to systemd utterly destroying the Linux community.

        • (Score: 0) by Anonymous Coward on Sunday October 12 2014, @09:14PM

          by Anonymous Coward on Sunday October 12 2014, @09:14PM (#105268)

          I'll keep using Debian no matter how much the anti-systemd jihadists carry on. That's freedom too, bitches!

  • (Score: 2) by hamsterdan on Sunday October 12 2014, @01:42AM

    by hamsterdan (2829) on Sunday October 12 2014, @01:42AM (#104933)

    In a purely accidental way, I was using BeyondTV at the time to record TV from two digital cable receivers. My HTPC case has a really nice VFD display on it (D.Vine SQ6), and I was using LCD Smartie to control it. One of the guys on Snapstream's forums wrote a plugin called BTV Smartie to fetch the information from Beyond TV (Show's name, channel, duration, etc). One of the shows didn't have any info whatsoever in the guide, so the plugin kinda garbled what the display was supposed to show).

    I simply reported it on the forum (and what lead to the bug), and his answer was:

    "And that would be a bug, nice catch!" (bug was fixed the next day)

    Just be nice when reporting bugs (and more importantly, explain what circumstances caused it so it helps the developer)

    • (Score: 2) by hamsterdan on Sunday October 12 2014, @01:44AM

      by hamsterdan (2829) on Sunday October 12 2014, @01:44AM (#104935)

      Forgot to add, in most cases, fixing bugs is more important than adding features (looking at you Firefox)

      Speaking of bugs, clicking submit 3 times did nothing so far...

      • (Score: 1) by GeminiDomino on Sunday October 12 2014, @04:09AM

        by GeminiDomino (661) on Sunday October 12 2014, @04:09AM (#104971)

        Forgot to add, in most cases, fixing bugs is more important than adding features (looking at you Firefox)

        Yeah, but that gets rather tricky when you can't tell the difference (also looking at you, Firefox).

        --
        "We've been attacked by the intelligent, educated segment of our culture"
  • (Score: 2) by Snotnose on Sunday October 12 2014, @02:14AM

    by Snotnose (1623) on Sunday October 12 2014, @02:14AM (#104943)

    It's hard enough with C/C++/Java/C#/Python/Perl/etc, but when you use crap (yeah, flamebait, I know) like javascript/ecmascript you're pretty much guaranteeing that even after a year of testing, thousands of test cases, on hundreds of installations, over a few months, somebody somewhere will have both Angry Birds and Plague Inc installed with a deleted copy of Where's my Water that will trigger a completely random bug.

    If you're Apollo or a Space Shuttle you can do pretty good testing, But in today's profusion of crap you will run across bugs that you could never test for.

    --
    Why shouldn't we judge a book by it's cover? It's got the author, title, and a summary of what the book's about.
    • (Score: 3, Informative) by tibman on Sunday October 12 2014, @07:45AM

      by tibman (134) Subscriber Badge on Sunday October 12 2014, @07:45AM (#104996)

      Javascript is unique in that the runtime environment varies from person to person. There is no official browser for javascript. There are competing solutions, varied interpretations of spec, and experimental api. Any language dealing with that would have a hard time. That being said, most people who write javascript never learn how to write it well. They think it's a shitty language so they never try to master it. So they will continue to write shit in a shitty language. Some people think C# is shitty, some think Perl is shitty, and so on. I think you should pick the best tool for the job. Currently JS is the best tool for client-side web interactivity. I'm not talking about crazy web 2.0 stuff either. Data validation alone is a perfect reason to use it. To each their own though : )

      --
      SN won't survive on lurkers alone. Write comments.
  • (Score: 2, Informative) by tnt118 on Sunday October 12 2014, @02:26AM

    by tnt118 (3925) on Sunday October 12 2014, @02:26AM (#104947)

    Over the years I've found (IMO) a fair amount of bugs or problems with various software that I've used. Typically these would be industry-specific specialized items, or some niche apps on the smartphone market. Part of my job is to push our software to the limit, to make sure we're using it to its maximum potential. It actually brings a smile to my face when I can find a unique situation that causes software to act in a way unanticipated by the developer.

    In my experience a well written, well thought out, and detailed bug report with the appropriate tone has ALWAYS been well received and quickly corrected. My goal and the developers are the same -- to have better and more stable software with a robust feature set. I'm pretty picky about what software I use when I have a choice. If I'm going to take a not insignificant amount of time to figure out how to recreate a bug, detail the situation and spell it out in an email it's because I genuinely want the software to be better.

    It took me a long time to accept that software would not be perfect, and that it takes folks in the field finding -- and then helping fix -- problems that do crop up. I never ended up in the programming field myself despite some interest when I was younger... but I feel that this process keeps me a half-step closer to being in the loop than I otherwise would have been.

    --
    I think I like it here.
  • (Score: 0) by Anonymous Coward on Sunday October 12 2014, @03:25AM

    by Anonymous Coward on Sunday October 12 2014, @03:25AM (#104957)

    Right up until 2000, the Standard Operating Procedure was to get the product Feature Complete, then pass it off to QA, who would then report bugs, and you would go back and forth until the product was regarded as working well enough to ship.

    I started working in the industry in 1987, and so I've seen a lot of bugs in my day.

    I don't know that one must fix absolutely every bug immediately, but it's quite a lot easier to get a good quality product shipped if you fix most bugs soon.

    Consider that if you don't fix a bug, then you add a feature. Your feature might have to compensate for that bug somehow in order to work at all. Now you fix that original bug - and you broke your feature.

  • (Score: 3, Insightful) by halcyon1234 on Sunday October 12 2014, @03:38AM

    by halcyon1234 (1082) on Sunday October 12 2014, @03:38AM (#104959)

    Really? In 2014? We need to ask how?

    1. Thank you for reporting this. I appreciate the time and effort you put into this, it is a real help. I apologize for any inconvenience this may have caused you.
    2. Option: Can you please provide some more details to help me (list of everything you need, and instructions on how to get those details)
    3. Depending on criticality to bug: Myself/team are working on solving this right away *OR* Here's an expected timeline of a fix *OR* this will be addressed in the future.

    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

      by microtodd (1866) on Sunday October 12 2014, @01:22PM (#105044) Homepage Journal

      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

      by RaffArundel (3108) on Monday October 13 2014, @03:19PM (#105576) Homepage

      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.

  • (Score: 2) by Grishnakh on Sunday October 12 2014, @04:42AM

    by Grishnakh (2831) on Sunday October 12 2014, @04:42AM (#104974)

    The key, then, is how do you respond? David Cummings has some thoughts on how to handle these scenarios.

    Why would Dave Cummings [wikipedia.org] have anything to say about bugs in software?

    • (Score: 0) by Anonymous Coward on Sunday October 12 2014, @04:02PM

      by Anonymous Coward on Sunday October 12 2014, @04:02PM (#105079)

      Dave's not here, man.

  • (Score: 2) by jasassin on Sunday October 12 2014, @06:30AM

    by jasassin (3566) <jasassin@gmail.com> on Sunday October 12 2014, @06:30AM (#104986) Homepage Journal

    I've never had a bug in any software I've written.

    --
    jasassin@gmail.com GPG Key ID: 0xE6462C68A9A3DB5A
    • (Score: 2) by VLM on Sunday October 12 2014, @04:22PM

      by VLM (445) Subscriber Badge on Sunday October 12 2014, @04:22PM (#105083)

      So, recently I shipped engineering software to "thousands of users", and one team was highly displeased because in their opinion the ONLY proper way to enter scientific notation is like "3.4-5" No that's not -1.6, that's the one true way to record 3.4x10e-5 or about 10 other ways to format it which I do permit as a limited form of input sanitation. And I must have input sanitation because other users pencil whip the system by entering 0-0-0-0-0 or 0.0.0.0.0 and their bosses don't care but the eventual downstream data users freak out. Its been a steady march for years starting from "we're all adults here with reactive supervisors so I'll trust you and only length check the data input buffer any UTF-8 is fine" to "Yeah technically computers can verify input formats as group B demands but group C has got to be kidding me". Meanwhile other folks are just entering 0 for all data so "how bout I take the average and std deviation of all inputs and then fail out if both the avg and std deviation are (something small)". I'll get right on that, after I figure out how to parse everything numeric up to and including Roman Numerals and Egyptian Hieroglyphics and keyboard entered Morse code. In javascript on the browser, before they get to submit the junk data. Not even kidding.

      This is supposedly a professional electronics / telecom engineering org with educated, or at least trained, employees and reactive management, BTW, not just random dudes off the street who don't know their numbers.

      If you're a dev and you're not saying WTF on a regular basis, you're just not dealing with the right (wrong?) bunch of end users.

  • (Score: 2) by PizzaRollPlinkett on Sunday October 12 2014, @07:50PM

    by PizzaRollPlinkett (4512) on Sunday October 12 2014, @07:50PM (#105224)

    Thankful someone actually used software that I wrote, I guess.

    Some bugs are just screwups. I felt good when Apple had to release a bug fix for a bug fix recently, because I had just done the same thing. If Apple can't get it right, then I'm not so bad either. And sometimes no matter how much myself or internal testers use software, 5 min after we release it someone finds a bug that happens under some obscure set of conditions no one ever thought of.

    But a lot of times you don't understand what you have. Bugs are a chance to understand how users actually want to use your software, and to improve it. The "bug" is a mismatch between what they want to do and what the software does now, and if you can fix the mismatch, you'll improve the software for a lot of people.

    --
    (E-mail me if you want a pizza roll!)