Non technical manager giving nonsensical implications [closed]

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP





.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;







up vote
33
down vote

favorite
1












I work in IT, with coding. Our technical manager is away and I've been asked to fix a bug by his non technical superior. So far so normal.



Now I've fixed it, hes asked what the problem was, which I explained. Now he's implying that bugs are not permitable, which is nonsense, as reducing bugs to zero is a fools errand. No programmer I've ever met believes this is achievable.



How do I handle this without appearing evasive or hostile?







share|improve this question











closed as off-topic by Jim G., Lilienthal♦, gnat, mcknz, Chris E Jun 30 '16 at 19:03



  • This question does not appear to be about the workplace within the scope defined in the help center.
If this question can be reworded to fit the rules in the help center, please edit the question.








  • 11




    Related on Programmers: There's no such thing as zero bug programming and it should never be a goal.
    – Lilienthal♦
    Jun 30 '16 at 11:08







  • 2




    I'm voting to close this question as off-topic because it's already been answered on programmers.stackexchange.com. programmers.stackexchange.com/questions/41248/…
    – Jim G.
    Jun 30 '16 at 11:10







  • 32




    Why do you have to "handle it"? You said they just implied their stance on bugs and you have not mentioned that you have been asked or even commanded to do anything differently. It sounds like a casual soundbite from a disgruntled boss a couple of levels up from the coalface- in 10 minutes they'll be pontificating over something else. Unless you have specifically been asked to do "something", I would just let it go and let the Tech Manager deal with it, if it is even still a matter for concern, on their return...
    – Marv Mills
    Jun 30 '16 at 11:32






  • 1




    Some old adages from an old programmer: There are always n+1 bugs. You can't make things foolproof because fools are so damn ingenious. If you allow for every possible condition, some ingenious idiot will manage to invent a new one by misusing your software and bring down the whole system. so, no. not possible to be bug-free
    – Richard U
    Jun 30 '16 at 14:24






  • 5




    Your current problem is the reason why you have a technical manager: so he or she deals with this problem. Just agree and wait for your real manager to come back :)
    – Mr Me
    Jun 30 '16 at 14:39
















up vote
33
down vote

favorite
1












I work in IT, with coding. Our technical manager is away and I've been asked to fix a bug by his non technical superior. So far so normal.



Now I've fixed it, hes asked what the problem was, which I explained. Now he's implying that bugs are not permitable, which is nonsense, as reducing bugs to zero is a fools errand. No programmer I've ever met believes this is achievable.



How do I handle this without appearing evasive or hostile?







share|improve this question











closed as off-topic by Jim G., Lilienthal♦, gnat, mcknz, Chris E Jun 30 '16 at 19:03



  • This question does not appear to be about the workplace within the scope defined in the help center.
If this question can be reworded to fit the rules in the help center, please edit the question.








  • 11




    Related on Programmers: There's no such thing as zero bug programming and it should never be a goal.
    – Lilienthal♦
    Jun 30 '16 at 11:08







  • 2




    I'm voting to close this question as off-topic because it's already been answered on programmers.stackexchange.com. programmers.stackexchange.com/questions/41248/…
    – Jim G.
    Jun 30 '16 at 11:10







  • 32




    Why do you have to "handle it"? You said they just implied their stance on bugs and you have not mentioned that you have been asked or even commanded to do anything differently. It sounds like a casual soundbite from a disgruntled boss a couple of levels up from the coalface- in 10 minutes they'll be pontificating over something else. Unless you have specifically been asked to do "something", I would just let it go and let the Tech Manager deal with it, if it is even still a matter for concern, on their return...
    – Marv Mills
    Jun 30 '16 at 11:32






  • 1




    Some old adages from an old programmer: There are always n+1 bugs. You can't make things foolproof because fools are so damn ingenious. If you allow for every possible condition, some ingenious idiot will manage to invent a new one by misusing your software and bring down the whole system. so, no. not possible to be bug-free
    – Richard U
    Jun 30 '16 at 14:24






  • 5




    Your current problem is the reason why you have a technical manager: so he or she deals with this problem. Just agree and wait for your real manager to come back :)
    – Mr Me
    Jun 30 '16 at 14:39












up vote
33
down vote

favorite
1









up vote
33
down vote

favorite
1






1





I work in IT, with coding. Our technical manager is away and I've been asked to fix a bug by his non technical superior. So far so normal.



Now I've fixed it, hes asked what the problem was, which I explained. Now he's implying that bugs are not permitable, which is nonsense, as reducing bugs to zero is a fools errand. No programmer I've ever met believes this is achievable.



How do I handle this without appearing evasive or hostile?







share|improve this question











I work in IT, with coding. Our technical manager is away and I've been asked to fix a bug by his non technical superior. So far so normal.



Now I've fixed it, hes asked what the problem was, which I explained. Now he's implying that bugs are not permitable, which is nonsense, as reducing bugs to zero is a fools errand. No programmer I've ever met believes this is achievable.



How do I handle this without appearing evasive or hostile?









share|improve this question










share|improve this question




share|improve this question









asked Jun 30 '16 at 10:47









Zap

17223




17223




closed as off-topic by Jim G., Lilienthal♦, gnat, mcknz, Chris E Jun 30 '16 at 19:03



  • This question does not appear to be about the workplace within the scope defined in the help center.
If this question can be reworded to fit the rules in the help center, please edit the question.




closed as off-topic by Jim G., Lilienthal♦, gnat, mcknz, Chris E Jun 30 '16 at 19:03



  • This question does not appear to be about the workplace within the scope defined in the help center.
If this question can be reworded to fit the rules in the help center, please edit the question.







  • 11




    Related on Programmers: There's no such thing as zero bug programming and it should never be a goal.
    – Lilienthal♦
    Jun 30 '16 at 11:08







  • 2




    I'm voting to close this question as off-topic because it's already been answered on programmers.stackexchange.com. programmers.stackexchange.com/questions/41248/…
    – Jim G.
    Jun 30 '16 at 11:10







  • 32




    Why do you have to "handle it"? You said they just implied their stance on bugs and you have not mentioned that you have been asked or even commanded to do anything differently. It sounds like a casual soundbite from a disgruntled boss a couple of levels up from the coalface- in 10 minutes they'll be pontificating over something else. Unless you have specifically been asked to do "something", I would just let it go and let the Tech Manager deal with it, if it is even still a matter for concern, on their return...
    – Marv Mills
    Jun 30 '16 at 11:32






  • 1




    Some old adages from an old programmer: There are always n+1 bugs. You can't make things foolproof because fools are so damn ingenious. If you allow for every possible condition, some ingenious idiot will manage to invent a new one by misusing your software and bring down the whole system. so, no. not possible to be bug-free
    – Richard U
    Jun 30 '16 at 14:24






  • 5




    Your current problem is the reason why you have a technical manager: so he or she deals with this problem. Just agree and wait for your real manager to come back :)
    – Mr Me
    Jun 30 '16 at 14:39












  • 11




    Related on Programmers: There's no such thing as zero bug programming and it should never be a goal.
    – Lilienthal♦
    Jun 30 '16 at 11:08







  • 2




    I'm voting to close this question as off-topic because it's already been answered on programmers.stackexchange.com. programmers.stackexchange.com/questions/41248/…
    – Jim G.
    Jun 30 '16 at 11:10







  • 32




    Why do you have to "handle it"? You said they just implied their stance on bugs and you have not mentioned that you have been asked or even commanded to do anything differently. It sounds like a casual soundbite from a disgruntled boss a couple of levels up from the coalface- in 10 minutes they'll be pontificating over something else. Unless you have specifically been asked to do "something", I would just let it go and let the Tech Manager deal with it, if it is even still a matter for concern, on their return...
    – Marv Mills
    Jun 30 '16 at 11:32






  • 1




    Some old adages from an old programmer: There are always n+1 bugs. You can't make things foolproof because fools are so damn ingenious. If you allow for every possible condition, some ingenious idiot will manage to invent a new one by misusing your software and bring down the whole system. so, no. not possible to be bug-free
    – Richard U
    Jun 30 '16 at 14:24






  • 5




    Your current problem is the reason why you have a technical manager: so he or she deals with this problem. Just agree and wait for your real manager to come back :)
    – Mr Me
    Jun 30 '16 at 14:39







11




11




Related on Programmers: There's no such thing as zero bug programming and it should never be a goal.
– Lilienthal♦
Jun 30 '16 at 11:08





Related on Programmers: There's no such thing as zero bug programming and it should never be a goal.
– Lilienthal♦
Jun 30 '16 at 11:08





2




2




I'm voting to close this question as off-topic because it's already been answered on programmers.stackexchange.com. programmers.stackexchange.com/questions/41248/…
– Jim G.
Jun 30 '16 at 11:10





I'm voting to close this question as off-topic because it's already been answered on programmers.stackexchange.com. programmers.stackexchange.com/questions/41248/…
– Jim G.
Jun 30 '16 at 11:10





32




32




Why do you have to "handle it"? You said they just implied their stance on bugs and you have not mentioned that you have been asked or even commanded to do anything differently. It sounds like a casual soundbite from a disgruntled boss a couple of levels up from the coalface- in 10 minutes they'll be pontificating over something else. Unless you have specifically been asked to do "something", I would just let it go and let the Tech Manager deal with it, if it is even still a matter for concern, on their return...
– Marv Mills
Jun 30 '16 at 11:32




Why do you have to "handle it"? You said they just implied their stance on bugs and you have not mentioned that you have been asked or even commanded to do anything differently. It sounds like a casual soundbite from a disgruntled boss a couple of levels up from the coalface- in 10 minutes they'll be pontificating over something else. Unless you have specifically been asked to do "something", I would just let it go and let the Tech Manager deal with it, if it is even still a matter for concern, on their return...
– Marv Mills
Jun 30 '16 at 11:32




1




1




Some old adages from an old programmer: There are always n+1 bugs. You can't make things foolproof because fools are so damn ingenious. If you allow for every possible condition, some ingenious idiot will manage to invent a new one by misusing your software and bring down the whole system. so, no. not possible to be bug-free
– Richard U
Jun 30 '16 at 14:24




Some old adages from an old programmer: There are always n+1 bugs. You can't make things foolproof because fools are so damn ingenious. If you allow for every possible condition, some ingenious idiot will manage to invent a new one by misusing your software and bring down the whole system. so, no. not possible to be bug-free
– Richard U
Jun 30 '16 at 14:24




5




5




Your current problem is the reason why you have a technical manager: so he or she deals with this problem. Just agree and wait for your real manager to come back :)
– Mr Me
Jun 30 '16 at 14:39




Your current problem is the reason why you have a technical manager: so he or she deals with this problem. Just agree and wait for your real manager to come back :)
– Mr Me
Jun 30 '16 at 14:39










7 Answers
7






active

oldest

votes

















up vote
71
down vote













Just "thank him for sharing". Something like




I agree, the fewer bugs we have the better.




Then include one sentence (two at the most) that are relevant to this situation.



  • when the users change their minds about what they want, that's not really a bug, even though we have to make the change

  • we have added automatic testing since that code was written, so new code will never have that particular problem. I wish we had the budget to add it throughout the entire program, but I understand it's just too expensive

  • I can audit all the similar code in the system to make sure that oversight wasn't duplicated anywhere else. It should take me about a day.

  • that mistake is common [in this language, on this platform, from new developers] and I've been wishing that [we had a coding standard, we did code reviews, we had automated testing, we practiced continuous integration, ...] so that we could prevent that sort of thing [or catch it much more quickly] - this is your chance to plug a "pet project" up a level from where you normally do, but don't overdo that, just drop a sentence or so and leave it unless the grandboss follows up on it.

Pretty much anything except




yeah, bugs happen, whaddayagonnado, luckily the users find most of them and it's not like quality matters or anything




You can share the nontechnical manager's desire to have as few bugs as humanly possible and to care about the quality without agreeing that the only acceptable number of bugs is zero. You can even increase the chances of a change you want happening. Listen hard for the underlying message instead of dismissing the manager as nontechnical and insisting the bug count will always be positive. That's not the point at all.






share|improve this answer

















  • 2




    Replace "about a day" by "approximately 2-3 years" to make better impact.
    – PlasmaHH
    Jun 30 '16 at 13:54






  • 10




    Assuming the technical manager is coming back in the not-too-distant future, I would say the first part and leave it at that and say as little as possible. Basically exit the conversation gracefully and then keep my head down until the person who understands how things work comes back. It's that person's job to manage upwards on the issue of bugs and coding in general.
    – Todd Wilcox
    Jun 30 '16 at 13:57






  • 1




    @ToddWilcox +1 that's the main reason middle management exists in almost any enterprise, to translate between the front line and senior levels.
    – Jared Smith
    Jun 30 '16 at 14:22










  • one or two sentences won't hurt, @ToddWilcox, and could help a lot. Otherwise you're just tugging your forelock and saying "sorry sir, will try harder sir" which helps no-one. english.stackexchange.com/questions/238012/pull-my-forelock Agree don't start a whole thing of it.
    – Kate Gregory
    Jun 30 '16 at 14:24











  • Using this manager's comment to further an agenda of developing better programming practices is fine, but don't lead them to believe that any programming practice is going to result in zero bugs.
    – Kik
    Jun 30 '16 at 18:33

















up vote
23
down vote













Wow, missed opportunity. You should be saying something along the lines of:



"Absolutely! But you know there always ends up being a tradeoff between delivering on time and design /testing/ code review. It would be great if we could look at this and timescales with a view to both delivering a better product and reducing bug counts".



Then you can look at making things better, rather than avoid his comments.



The thing is do the metrics. If you fix a bug, look at the root cause. If you can say "this bug happened because of a subsequent change in component z, and took y days to fix, it would have taken me w hours to write a test suite and we could have caught it at integration, thus saving y-(w/working day)"






share|improve this answer























  • Only on the condition you're prepared to imbue 30 years of technical industry knowledge into the nontech manager.
    – user42272
    Jun 30 '16 at 18:11










  • No that's the point, you take it to a simple equation, you want fewer bugs, give us more time to do things right, no technical understanding required (or wanted by the boss's boss). These guys don't want the gory details, you pitch it as "do x get y"
    – The Wandering Dev Manager
    Jun 30 '16 at 19:32











  • No, "do x" means "give us a ton more time", managers don't just give a ton more time (i.e. money) for no reason and tend to not listen to a lower-level employee they just met trying to rearchitect their budget in 5 minutes or less.
    – user42272
    Jun 30 '16 at 19:43










  • No but you do a Scotty, give me x time and I'll make things y better, making sure x is bigger than you need so you then look like a miracle worker. These guys want to see control, be desicive and they'll back you, be wishy washy (I need a ton more time and I might make it better) and they won't bite. Look at what you spend on bug fixing now (10%? 20%?), ask for half that and make it better (doesn't need to be perfect if you can show the gain) , everyone wins.
    – The Wandering Dev Manager
    Jun 30 '16 at 19:50











  • I mean, maybe. Depends on manager's personality and OP's diplomacy. I really would note there's a lot of risk to this approach, I mean my honest feeling is the manager will just hear excuses for there being bugs in the first place, given their attitude in the first place. YMMV but I don't appreciate that this answer is just telling one side of this story without discussing how this may turn out to be a hard sell and at worst basically sounds sarcastic and excuse-making.
    – user42272
    Jun 30 '16 at 20:30

















up vote
7
down vote













Unfortunately, I've been through a similar situation with a manager.



It seems your technical manager is away temporarily, so I would just wait until he is back, and then raise this problem with him.
It will be his job to talk to his non-technical manager and making him understand that zero bugs is not realistic.



You can mention to your manager that you are happy to provide arguments on why zero bugs is impossible, so he can see you are showing initiative to help solving this situation.






share|improve this answer




























    up vote
    6
    down vote













    Joe Spolsky has an interesting article referring to Microsoft's "zero defects methodology". I wonder if your non-technical manager may have been thinking of something like this. Maybe he wasn't saying that bugs shouldn't exist, but rather that they should be addressed before other things or marked as won't fix.



    Here is an excerpt from the article The Joel Test: 12 Steps to Better Code:




    Do you fix bugs before writing new code?



    The very first version of Microsoft Word for Windows was considered a "death march" project. It
    took forever. It kept slipping. The whole team was working ridiculous
    hours, the project was delayed again, and again, and again, and the
    stress was incredible. When the dang thing finally shipped, years
    late, Microsoft sent the whole team off to Cancun for a vacation, then
    sat down for some serious soul-searching.



    What they realized was that the project managers had been so insistent
    on keeping to the "schedule" that programmers simply rushed through
    the coding process, writing extremely bad code, because the bug fixing
    phase was not a part of the formal schedule. There was no attempt to
    keep the bug-count down. Quite the opposite. The story goes that one
    programmer, who had to write the code to calculate the height of a
    line of text, simply wrote "return 12;" and waited for the bug report
    to come in about how his function is not always correct. The schedule
    was merely a checklist of features waiting to be turned into bugs. In
    the post-mortem, this was referred to as "infinite defects
    methodology".



    To correct the problem, Microsoft universally adopted something called
    a "zero defects methodology". Many of the programmers in the company
    giggled, since it sounded like management thought they could reduce
    the bug count by executive fiat. Actually, "zero defects" meant that
    at any given time, the highest priority is to eliminate bugs before
    writing any new code. Here's why.



    In general, the longer you wait before fixing a bug, the costlier (in
    time and money) it is to fix.



    For example, when you make a typo or syntax error that the compiler
    catches, fixing it is basically trivial.



    When you have a bug in your code that you see the first time you try
    to run it, you will be able to fix it in no time at all, because all
    the code is still fresh in your mind.



    If you find a bug in some code that you wrote a few days ago, it will
    take you a while to hunt it down, but when you reread the code you
    wrote, you'll remember everything and you'll be able to fix the bug in
    a reasonable amount of time.



    But if you find a bug in code that you wrote a few months ago, you'll
    probably have forgotten a lot of things about that code, and it's much
    harder to fix. By that time you may be fixing somebody else's code,
    and they may be in Aruba on vacation, in which case, fixing the bug is
    like science: you have to be slow, methodical, and meticulous, and you
    can't be sure how long it will take to discover the cure.



    And if you find a bug in code that has already shipped, you're going
    to incur incredible expense getting it fixed.



    That's one reason to fix bugs right away: because it takes less time.
    There's another reason, which relates to the fact that it's easier to
    predict how long it will take to write new code than to fix an
    existing bug. For example, if I asked you to predict how long it would
    take to write the code to sort a list, you could give me a pretty good
    estimate. But if I asked you how to predict how long it would take to
    fix that bug where your code doesn't work if Internet Explorer 5.5 is
    installed, you can't even guess, because you don't know (by
    definition) what's causing the bug. It could take 3 days to track it
    down, or it could take 2 minutes.



    What this means is that if you have a schedule with a lot of bugs
    remaining to be fixed, the schedule is unreliable. But if you've fixed
    all the known bugs, and all that's left is new code, then your
    schedule will be stunningly more accurate.



    Another great thing about keeping the bug count at zero is that you
    can respond much faster to competition. Some programmers think of this
    as keeping the product ready to ship at all times. Then if your
    competitor introduces a killer new feature that is stealing your
    customers, you can implement just that feature and ship on the spot,
    without having to fix a large number of accumulated bugs.




    Source






    share|improve this answer





















    • Microsoft is not really a shinning example for a company that does not have a truckload of bugs.
      – Rui F Ribeiro
      Jun 30 '16 at 16:02

















    up vote
    5
    down vote













    Is there something that the business could do to have less bugs? Maybe cleaning up technical debt? Maybe recruiting specific people to test software? Maybe less tight deadlines?



    If you would like any of those things to happen in your organisation you could bring it up when the person asks you to produce fewer bugs.






    share|improve this answer





















    • Of course you can. If the boss gives you the budget.
      – gnasher729
      Jun 30 '16 at 17:55










    • @gnasher729 : A likely response might be that the boss stops caring about bug-free code if you explain what reducing bugs would require. That completely works for the purposes of this exchange.
      – Christian
      Jun 30 '16 at 18:43


















    up vote
    0
    down vote













    Perhaps a explanation along these lines could work:



    All code rests on assumptions - which may turn out to be wrong or even start out as correct, but later become false.



    Quite often, it is assumed that user input validation is centralized, so underlying services assume their input data is valid. If someone else bypasses this central validation, bugs will be expected.



    Very few bugs are created on purpose, but rather because another developer changed code without being aware of the assumptions related to that code.



    Sadly, most code is undocumented, meaning developers need to make educated guesses regarding use. Others times, documentation exists, but only as way too long templated Word documents that typically bury the relevant stuff in tons of boilerplate. In addition, the more documentation, the less likely that is has actually been updated when the code changes.






    share|improve this answer




























      up vote
      0
      down vote













      All the other answers advice you to discuss this view point of your nontechnical manager with him/her and they somehow imply that it is possible to educate and correct him/her. They completely disregard the fact that nontechnical managers have a handicap. They tend to be complely convinced that their viewpoints, however ridiculous, are pearls of wisdom because they are ... managers. Giving them a response that goes against their preconceived notions will hurt their considerable egos and will only invite their displeasure, more scrutiny, interference and micromanagement for your team.



      Instead give a brief response agreeing with this nontechnical genius (just nod your head if meeting in person or respond back with a brief "We will work on it right away" if by email) and promptly put the whole episode out of your mind. His ego remains intact and you can focus on your work - a win for you, your team, your customers and your company.






      share|improve this answer




























        7 Answers
        7






        active

        oldest

        votes








        7 Answers
        7






        active

        oldest

        votes









        active

        oldest

        votes






        active

        oldest

        votes








        up vote
        71
        down vote













        Just "thank him for sharing". Something like




        I agree, the fewer bugs we have the better.




        Then include one sentence (two at the most) that are relevant to this situation.



        • when the users change their minds about what they want, that's not really a bug, even though we have to make the change

        • we have added automatic testing since that code was written, so new code will never have that particular problem. I wish we had the budget to add it throughout the entire program, but I understand it's just too expensive

        • I can audit all the similar code in the system to make sure that oversight wasn't duplicated anywhere else. It should take me about a day.

        • that mistake is common [in this language, on this platform, from new developers] and I've been wishing that [we had a coding standard, we did code reviews, we had automated testing, we practiced continuous integration, ...] so that we could prevent that sort of thing [or catch it much more quickly] - this is your chance to plug a "pet project" up a level from where you normally do, but don't overdo that, just drop a sentence or so and leave it unless the grandboss follows up on it.

        Pretty much anything except




        yeah, bugs happen, whaddayagonnado, luckily the users find most of them and it's not like quality matters or anything




        You can share the nontechnical manager's desire to have as few bugs as humanly possible and to care about the quality without agreeing that the only acceptable number of bugs is zero. You can even increase the chances of a change you want happening. Listen hard for the underlying message instead of dismissing the manager as nontechnical and insisting the bug count will always be positive. That's not the point at all.






        share|improve this answer

















        • 2




          Replace "about a day" by "approximately 2-3 years" to make better impact.
          – PlasmaHH
          Jun 30 '16 at 13:54






        • 10




          Assuming the technical manager is coming back in the not-too-distant future, I would say the first part and leave it at that and say as little as possible. Basically exit the conversation gracefully and then keep my head down until the person who understands how things work comes back. It's that person's job to manage upwards on the issue of bugs and coding in general.
          – Todd Wilcox
          Jun 30 '16 at 13:57






        • 1




          @ToddWilcox +1 that's the main reason middle management exists in almost any enterprise, to translate between the front line and senior levels.
          – Jared Smith
          Jun 30 '16 at 14:22










        • one or two sentences won't hurt, @ToddWilcox, and could help a lot. Otherwise you're just tugging your forelock and saying "sorry sir, will try harder sir" which helps no-one. english.stackexchange.com/questions/238012/pull-my-forelock Agree don't start a whole thing of it.
          – Kate Gregory
          Jun 30 '16 at 14:24











        • Using this manager's comment to further an agenda of developing better programming practices is fine, but don't lead them to believe that any programming practice is going to result in zero bugs.
          – Kik
          Jun 30 '16 at 18:33














        up vote
        71
        down vote













        Just "thank him for sharing". Something like




        I agree, the fewer bugs we have the better.




        Then include one sentence (two at the most) that are relevant to this situation.



        • when the users change their minds about what they want, that's not really a bug, even though we have to make the change

        • we have added automatic testing since that code was written, so new code will never have that particular problem. I wish we had the budget to add it throughout the entire program, but I understand it's just too expensive

        • I can audit all the similar code in the system to make sure that oversight wasn't duplicated anywhere else. It should take me about a day.

        • that mistake is common [in this language, on this platform, from new developers] and I've been wishing that [we had a coding standard, we did code reviews, we had automated testing, we practiced continuous integration, ...] so that we could prevent that sort of thing [or catch it much more quickly] - this is your chance to plug a "pet project" up a level from where you normally do, but don't overdo that, just drop a sentence or so and leave it unless the grandboss follows up on it.

        Pretty much anything except




        yeah, bugs happen, whaddayagonnado, luckily the users find most of them and it's not like quality matters or anything




        You can share the nontechnical manager's desire to have as few bugs as humanly possible and to care about the quality without agreeing that the only acceptable number of bugs is zero. You can even increase the chances of a change you want happening. Listen hard for the underlying message instead of dismissing the manager as nontechnical and insisting the bug count will always be positive. That's not the point at all.






        share|improve this answer

















        • 2




          Replace "about a day" by "approximately 2-3 years" to make better impact.
          – PlasmaHH
          Jun 30 '16 at 13:54






        • 10




          Assuming the technical manager is coming back in the not-too-distant future, I would say the first part and leave it at that and say as little as possible. Basically exit the conversation gracefully and then keep my head down until the person who understands how things work comes back. It's that person's job to manage upwards on the issue of bugs and coding in general.
          – Todd Wilcox
          Jun 30 '16 at 13:57






        • 1




          @ToddWilcox +1 that's the main reason middle management exists in almost any enterprise, to translate between the front line and senior levels.
          – Jared Smith
          Jun 30 '16 at 14:22










        • one or two sentences won't hurt, @ToddWilcox, and could help a lot. Otherwise you're just tugging your forelock and saying "sorry sir, will try harder sir" which helps no-one. english.stackexchange.com/questions/238012/pull-my-forelock Agree don't start a whole thing of it.
          – Kate Gregory
          Jun 30 '16 at 14:24











        • Using this manager's comment to further an agenda of developing better programming practices is fine, but don't lead them to believe that any programming practice is going to result in zero bugs.
          – Kik
          Jun 30 '16 at 18:33












        up vote
        71
        down vote










        up vote
        71
        down vote









        Just "thank him for sharing". Something like




        I agree, the fewer bugs we have the better.




        Then include one sentence (two at the most) that are relevant to this situation.



        • when the users change their minds about what they want, that's not really a bug, even though we have to make the change

        • we have added automatic testing since that code was written, so new code will never have that particular problem. I wish we had the budget to add it throughout the entire program, but I understand it's just too expensive

        • I can audit all the similar code in the system to make sure that oversight wasn't duplicated anywhere else. It should take me about a day.

        • that mistake is common [in this language, on this platform, from new developers] and I've been wishing that [we had a coding standard, we did code reviews, we had automated testing, we practiced continuous integration, ...] so that we could prevent that sort of thing [or catch it much more quickly] - this is your chance to plug a "pet project" up a level from where you normally do, but don't overdo that, just drop a sentence or so and leave it unless the grandboss follows up on it.

        Pretty much anything except




        yeah, bugs happen, whaddayagonnado, luckily the users find most of them and it's not like quality matters or anything




        You can share the nontechnical manager's desire to have as few bugs as humanly possible and to care about the quality without agreeing that the only acceptable number of bugs is zero. You can even increase the chances of a change you want happening. Listen hard for the underlying message instead of dismissing the manager as nontechnical and insisting the bug count will always be positive. That's not the point at all.






        share|improve this answer













        Just "thank him for sharing". Something like




        I agree, the fewer bugs we have the better.




        Then include one sentence (two at the most) that are relevant to this situation.



        • when the users change their minds about what they want, that's not really a bug, even though we have to make the change

        • we have added automatic testing since that code was written, so new code will never have that particular problem. I wish we had the budget to add it throughout the entire program, but I understand it's just too expensive

        • I can audit all the similar code in the system to make sure that oversight wasn't duplicated anywhere else. It should take me about a day.

        • that mistake is common [in this language, on this platform, from new developers] and I've been wishing that [we had a coding standard, we did code reviews, we had automated testing, we practiced continuous integration, ...] so that we could prevent that sort of thing [or catch it much more quickly] - this is your chance to plug a "pet project" up a level from where you normally do, but don't overdo that, just drop a sentence or so and leave it unless the grandboss follows up on it.

        Pretty much anything except




        yeah, bugs happen, whaddayagonnado, luckily the users find most of them and it's not like quality matters or anything




        You can share the nontechnical manager's desire to have as few bugs as humanly possible and to care about the quality without agreeing that the only acceptable number of bugs is zero. You can even increase the chances of a change you want happening. Listen hard for the underlying message instead of dismissing the manager as nontechnical and insisting the bug count will always be positive. That's not the point at all.







        share|improve this answer













        share|improve this answer



        share|improve this answer











        answered Jun 30 '16 at 10:57









        Kate Gregory

        104k40230331




        104k40230331







        • 2




          Replace "about a day" by "approximately 2-3 years" to make better impact.
          – PlasmaHH
          Jun 30 '16 at 13:54






        • 10




          Assuming the technical manager is coming back in the not-too-distant future, I would say the first part and leave it at that and say as little as possible. Basically exit the conversation gracefully and then keep my head down until the person who understands how things work comes back. It's that person's job to manage upwards on the issue of bugs and coding in general.
          – Todd Wilcox
          Jun 30 '16 at 13:57






        • 1




          @ToddWilcox +1 that's the main reason middle management exists in almost any enterprise, to translate between the front line and senior levels.
          – Jared Smith
          Jun 30 '16 at 14:22










        • one or two sentences won't hurt, @ToddWilcox, and could help a lot. Otherwise you're just tugging your forelock and saying "sorry sir, will try harder sir" which helps no-one. english.stackexchange.com/questions/238012/pull-my-forelock Agree don't start a whole thing of it.
          – Kate Gregory
          Jun 30 '16 at 14:24











        • Using this manager's comment to further an agenda of developing better programming practices is fine, but don't lead them to believe that any programming practice is going to result in zero bugs.
          – Kik
          Jun 30 '16 at 18:33












        • 2




          Replace "about a day" by "approximately 2-3 years" to make better impact.
          – PlasmaHH
          Jun 30 '16 at 13:54






        • 10




          Assuming the technical manager is coming back in the not-too-distant future, I would say the first part and leave it at that and say as little as possible. Basically exit the conversation gracefully and then keep my head down until the person who understands how things work comes back. It's that person's job to manage upwards on the issue of bugs and coding in general.
          – Todd Wilcox
          Jun 30 '16 at 13:57






        • 1




          @ToddWilcox +1 that's the main reason middle management exists in almost any enterprise, to translate between the front line and senior levels.
          – Jared Smith
          Jun 30 '16 at 14:22










        • one or two sentences won't hurt, @ToddWilcox, and could help a lot. Otherwise you're just tugging your forelock and saying "sorry sir, will try harder sir" which helps no-one. english.stackexchange.com/questions/238012/pull-my-forelock Agree don't start a whole thing of it.
          – Kate Gregory
          Jun 30 '16 at 14:24











        • Using this manager's comment to further an agenda of developing better programming practices is fine, but don't lead them to believe that any programming practice is going to result in zero bugs.
          – Kik
          Jun 30 '16 at 18:33







        2




        2




        Replace "about a day" by "approximately 2-3 years" to make better impact.
        – PlasmaHH
        Jun 30 '16 at 13:54




        Replace "about a day" by "approximately 2-3 years" to make better impact.
        – PlasmaHH
        Jun 30 '16 at 13:54




        10




        10




        Assuming the technical manager is coming back in the not-too-distant future, I would say the first part and leave it at that and say as little as possible. Basically exit the conversation gracefully and then keep my head down until the person who understands how things work comes back. It's that person's job to manage upwards on the issue of bugs and coding in general.
        – Todd Wilcox
        Jun 30 '16 at 13:57




        Assuming the technical manager is coming back in the not-too-distant future, I would say the first part and leave it at that and say as little as possible. Basically exit the conversation gracefully and then keep my head down until the person who understands how things work comes back. It's that person's job to manage upwards on the issue of bugs and coding in general.
        – Todd Wilcox
        Jun 30 '16 at 13:57




        1




        1




        @ToddWilcox +1 that's the main reason middle management exists in almost any enterprise, to translate between the front line and senior levels.
        – Jared Smith
        Jun 30 '16 at 14:22




        @ToddWilcox +1 that's the main reason middle management exists in almost any enterprise, to translate between the front line and senior levels.
        – Jared Smith
        Jun 30 '16 at 14:22












        one or two sentences won't hurt, @ToddWilcox, and could help a lot. Otherwise you're just tugging your forelock and saying "sorry sir, will try harder sir" which helps no-one. english.stackexchange.com/questions/238012/pull-my-forelock Agree don't start a whole thing of it.
        – Kate Gregory
        Jun 30 '16 at 14:24





        one or two sentences won't hurt, @ToddWilcox, and could help a lot. Otherwise you're just tugging your forelock and saying "sorry sir, will try harder sir" which helps no-one. english.stackexchange.com/questions/238012/pull-my-forelock Agree don't start a whole thing of it.
        – Kate Gregory
        Jun 30 '16 at 14:24













        Using this manager's comment to further an agenda of developing better programming practices is fine, but don't lead them to believe that any programming practice is going to result in zero bugs.
        – Kik
        Jun 30 '16 at 18:33




        Using this manager's comment to further an agenda of developing better programming practices is fine, but don't lead them to believe that any programming practice is going to result in zero bugs.
        – Kik
        Jun 30 '16 at 18:33












        up vote
        23
        down vote













        Wow, missed opportunity. You should be saying something along the lines of:



        "Absolutely! But you know there always ends up being a tradeoff between delivering on time and design /testing/ code review. It would be great if we could look at this and timescales with a view to both delivering a better product and reducing bug counts".



        Then you can look at making things better, rather than avoid his comments.



        The thing is do the metrics. If you fix a bug, look at the root cause. If you can say "this bug happened because of a subsequent change in component z, and took y days to fix, it would have taken me w hours to write a test suite and we could have caught it at integration, thus saving y-(w/working day)"






        share|improve this answer























        • Only on the condition you're prepared to imbue 30 years of technical industry knowledge into the nontech manager.
          – user42272
          Jun 30 '16 at 18:11










        • No that's the point, you take it to a simple equation, you want fewer bugs, give us more time to do things right, no technical understanding required (or wanted by the boss's boss). These guys don't want the gory details, you pitch it as "do x get y"
          – The Wandering Dev Manager
          Jun 30 '16 at 19:32











        • No, "do x" means "give us a ton more time", managers don't just give a ton more time (i.e. money) for no reason and tend to not listen to a lower-level employee they just met trying to rearchitect their budget in 5 minutes or less.
          – user42272
          Jun 30 '16 at 19:43










        • No but you do a Scotty, give me x time and I'll make things y better, making sure x is bigger than you need so you then look like a miracle worker. These guys want to see control, be desicive and they'll back you, be wishy washy (I need a ton more time and I might make it better) and they won't bite. Look at what you spend on bug fixing now (10%? 20%?), ask for half that and make it better (doesn't need to be perfect if you can show the gain) , everyone wins.
          – The Wandering Dev Manager
          Jun 30 '16 at 19:50











        • I mean, maybe. Depends on manager's personality and OP's diplomacy. I really would note there's a lot of risk to this approach, I mean my honest feeling is the manager will just hear excuses for there being bugs in the first place, given their attitude in the first place. YMMV but I don't appreciate that this answer is just telling one side of this story without discussing how this may turn out to be a hard sell and at worst basically sounds sarcastic and excuse-making.
          – user42272
          Jun 30 '16 at 20:30














        up vote
        23
        down vote













        Wow, missed opportunity. You should be saying something along the lines of:



        "Absolutely! But you know there always ends up being a tradeoff between delivering on time and design /testing/ code review. It would be great if we could look at this and timescales with a view to both delivering a better product and reducing bug counts".



        Then you can look at making things better, rather than avoid his comments.



        The thing is do the metrics. If you fix a bug, look at the root cause. If you can say "this bug happened because of a subsequent change in component z, and took y days to fix, it would have taken me w hours to write a test suite and we could have caught it at integration, thus saving y-(w/working day)"






        share|improve this answer























        • Only on the condition you're prepared to imbue 30 years of technical industry knowledge into the nontech manager.
          – user42272
          Jun 30 '16 at 18:11










        • No that's the point, you take it to a simple equation, you want fewer bugs, give us more time to do things right, no technical understanding required (or wanted by the boss's boss). These guys don't want the gory details, you pitch it as "do x get y"
          – The Wandering Dev Manager
          Jun 30 '16 at 19:32











        • No, "do x" means "give us a ton more time", managers don't just give a ton more time (i.e. money) for no reason and tend to not listen to a lower-level employee they just met trying to rearchitect their budget in 5 minutes or less.
          – user42272
          Jun 30 '16 at 19:43










        • No but you do a Scotty, give me x time and I'll make things y better, making sure x is bigger than you need so you then look like a miracle worker. These guys want to see control, be desicive and they'll back you, be wishy washy (I need a ton more time and I might make it better) and they won't bite. Look at what you spend on bug fixing now (10%? 20%?), ask for half that and make it better (doesn't need to be perfect if you can show the gain) , everyone wins.
          – The Wandering Dev Manager
          Jun 30 '16 at 19:50











        • I mean, maybe. Depends on manager's personality and OP's diplomacy. I really would note there's a lot of risk to this approach, I mean my honest feeling is the manager will just hear excuses for there being bugs in the first place, given their attitude in the first place. YMMV but I don't appreciate that this answer is just telling one side of this story without discussing how this may turn out to be a hard sell and at worst basically sounds sarcastic and excuse-making.
          – user42272
          Jun 30 '16 at 20:30












        up vote
        23
        down vote










        up vote
        23
        down vote









        Wow, missed opportunity. You should be saying something along the lines of:



        "Absolutely! But you know there always ends up being a tradeoff between delivering on time and design /testing/ code review. It would be great if we could look at this and timescales with a view to both delivering a better product and reducing bug counts".



        Then you can look at making things better, rather than avoid his comments.



        The thing is do the metrics. If you fix a bug, look at the root cause. If you can say "this bug happened because of a subsequent change in component z, and took y days to fix, it would have taken me w hours to write a test suite and we could have caught it at integration, thus saving y-(w/working day)"






        share|improve this answer















        Wow, missed opportunity. You should be saying something along the lines of:



        "Absolutely! But you know there always ends up being a tradeoff between delivering on time and design /testing/ code review. It would be great if we could look at this and timescales with a view to both delivering a better product and reducing bug counts".



        Then you can look at making things better, rather than avoid his comments.



        The thing is do the metrics. If you fix a bug, look at the root cause. If you can say "this bug happened because of a subsequent change in component z, and took y days to fix, it would have taken me w hours to write a test suite and we could have caught it at integration, thus saving y-(w/working day)"







        share|improve this answer















        share|improve this answer



        share|improve this answer








        edited Jun 30 '16 at 23:41


























        answered Jun 30 '16 at 12:38









        The Wandering Dev Manager

        29.8k956107




        29.8k956107











        • Only on the condition you're prepared to imbue 30 years of technical industry knowledge into the nontech manager.
          – user42272
          Jun 30 '16 at 18:11










        • No that's the point, you take it to a simple equation, you want fewer bugs, give us more time to do things right, no technical understanding required (or wanted by the boss's boss). These guys don't want the gory details, you pitch it as "do x get y"
          – The Wandering Dev Manager
          Jun 30 '16 at 19:32











        • No, "do x" means "give us a ton more time", managers don't just give a ton more time (i.e. money) for no reason and tend to not listen to a lower-level employee they just met trying to rearchitect their budget in 5 minutes or less.
          – user42272
          Jun 30 '16 at 19:43










        • No but you do a Scotty, give me x time and I'll make things y better, making sure x is bigger than you need so you then look like a miracle worker. These guys want to see control, be desicive and they'll back you, be wishy washy (I need a ton more time and I might make it better) and they won't bite. Look at what you spend on bug fixing now (10%? 20%?), ask for half that and make it better (doesn't need to be perfect if you can show the gain) , everyone wins.
          – The Wandering Dev Manager
          Jun 30 '16 at 19:50











        • I mean, maybe. Depends on manager's personality and OP's diplomacy. I really would note there's a lot of risk to this approach, I mean my honest feeling is the manager will just hear excuses for there being bugs in the first place, given their attitude in the first place. YMMV but I don't appreciate that this answer is just telling one side of this story without discussing how this may turn out to be a hard sell and at worst basically sounds sarcastic and excuse-making.
          – user42272
          Jun 30 '16 at 20:30
















        • Only on the condition you're prepared to imbue 30 years of technical industry knowledge into the nontech manager.
          – user42272
          Jun 30 '16 at 18:11










        • No that's the point, you take it to a simple equation, you want fewer bugs, give us more time to do things right, no technical understanding required (or wanted by the boss's boss). These guys don't want the gory details, you pitch it as "do x get y"
          – The Wandering Dev Manager
          Jun 30 '16 at 19:32











        • No, "do x" means "give us a ton more time", managers don't just give a ton more time (i.e. money) for no reason and tend to not listen to a lower-level employee they just met trying to rearchitect their budget in 5 minutes or less.
          – user42272
          Jun 30 '16 at 19:43










        • No but you do a Scotty, give me x time and I'll make things y better, making sure x is bigger than you need so you then look like a miracle worker. These guys want to see control, be desicive and they'll back you, be wishy washy (I need a ton more time and I might make it better) and they won't bite. Look at what you spend on bug fixing now (10%? 20%?), ask for half that and make it better (doesn't need to be perfect if you can show the gain) , everyone wins.
          – The Wandering Dev Manager
          Jun 30 '16 at 19:50











        • I mean, maybe. Depends on manager's personality and OP's diplomacy. I really would note there's a lot of risk to this approach, I mean my honest feeling is the manager will just hear excuses for there being bugs in the first place, given their attitude in the first place. YMMV but I don't appreciate that this answer is just telling one side of this story without discussing how this may turn out to be a hard sell and at worst basically sounds sarcastic and excuse-making.
          – user42272
          Jun 30 '16 at 20:30















        Only on the condition you're prepared to imbue 30 years of technical industry knowledge into the nontech manager.
        – user42272
        Jun 30 '16 at 18:11




        Only on the condition you're prepared to imbue 30 years of technical industry knowledge into the nontech manager.
        – user42272
        Jun 30 '16 at 18:11












        No that's the point, you take it to a simple equation, you want fewer bugs, give us more time to do things right, no technical understanding required (or wanted by the boss's boss). These guys don't want the gory details, you pitch it as "do x get y"
        – The Wandering Dev Manager
        Jun 30 '16 at 19:32





        No that's the point, you take it to a simple equation, you want fewer bugs, give us more time to do things right, no technical understanding required (or wanted by the boss's boss). These guys don't want the gory details, you pitch it as "do x get y"
        – The Wandering Dev Manager
        Jun 30 '16 at 19:32













        No, "do x" means "give us a ton more time", managers don't just give a ton more time (i.e. money) for no reason and tend to not listen to a lower-level employee they just met trying to rearchitect their budget in 5 minutes or less.
        – user42272
        Jun 30 '16 at 19:43




        No, "do x" means "give us a ton more time", managers don't just give a ton more time (i.e. money) for no reason and tend to not listen to a lower-level employee they just met trying to rearchitect their budget in 5 minutes or less.
        – user42272
        Jun 30 '16 at 19:43












        No but you do a Scotty, give me x time and I'll make things y better, making sure x is bigger than you need so you then look like a miracle worker. These guys want to see control, be desicive and they'll back you, be wishy washy (I need a ton more time and I might make it better) and they won't bite. Look at what you spend on bug fixing now (10%? 20%?), ask for half that and make it better (doesn't need to be perfect if you can show the gain) , everyone wins.
        – The Wandering Dev Manager
        Jun 30 '16 at 19:50





        No but you do a Scotty, give me x time and I'll make things y better, making sure x is bigger than you need so you then look like a miracle worker. These guys want to see control, be desicive and they'll back you, be wishy washy (I need a ton more time and I might make it better) and they won't bite. Look at what you spend on bug fixing now (10%? 20%?), ask for half that and make it better (doesn't need to be perfect if you can show the gain) , everyone wins.
        – The Wandering Dev Manager
        Jun 30 '16 at 19:50













        I mean, maybe. Depends on manager's personality and OP's diplomacy. I really would note there's a lot of risk to this approach, I mean my honest feeling is the manager will just hear excuses for there being bugs in the first place, given their attitude in the first place. YMMV but I don't appreciate that this answer is just telling one side of this story without discussing how this may turn out to be a hard sell and at worst basically sounds sarcastic and excuse-making.
        – user42272
        Jun 30 '16 at 20:30




        I mean, maybe. Depends on manager's personality and OP's diplomacy. I really would note there's a lot of risk to this approach, I mean my honest feeling is the manager will just hear excuses for there being bugs in the first place, given their attitude in the first place. YMMV but I don't appreciate that this answer is just telling one side of this story without discussing how this may turn out to be a hard sell and at worst basically sounds sarcastic and excuse-making.
        – user42272
        Jun 30 '16 at 20:30










        up vote
        7
        down vote













        Unfortunately, I've been through a similar situation with a manager.



        It seems your technical manager is away temporarily, so I would just wait until he is back, and then raise this problem with him.
        It will be his job to talk to his non-technical manager and making him understand that zero bugs is not realistic.



        You can mention to your manager that you are happy to provide arguments on why zero bugs is impossible, so he can see you are showing initiative to help solving this situation.






        share|improve this answer

























          up vote
          7
          down vote













          Unfortunately, I've been through a similar situation with a manager.



          It seems your technical manager is away temporarily, so I would just wait until he is back, and then raise this problem with him.
          It will be his job to talk to his non-technical manager and making him understand that zero bugs is not realistic.



          You can mention to your manager that you are happy to provide arguments on why zero bugs is impossible, so he can see you are showing initiative to help solving this situation.






          share|improve this answer























            up vote
            7
            down vote










            up vote
            7
            down vote









            Unfortunately, I've been through a similar situation with a manager.



            It seems your technical manager is away temporarily, so I would just wait until he is back, and then raise this problem with him.
            It will be his job to talk to his non-technical manager and making him understand that zero bugs is not realistic.



            You can mention to your manager that you are happy to provide arguments on why zero bugs is impossible, so he can see you are showing initiative to help solving this situation.






            share|improve this answer













            Unfortunately, I've been through a similar situation with a manager.



            It seems your technical manager is away temporarily, so I would just wait until he is back, and then raise this problem with him.
            It will be his job to talk to his non-technical manager and making him understand that zero bugs is not realistic.



            You can mention to your manager that you are happy to provide arguments on why zero bugs is impossible, so he can see you are showing initiative to help solving this situation.







            share|improve this answer













            share|improve this answer



            share|improve this answer











            answered Jun 30 '16 at 11:03









            Charmander

            2,51121024




            2,51121024




















                up vote
                6
                down vote













                Joe Spolsky has an interesting article referring to Microsoft's "zero defects methodology". I wonder if your non-technical manager may have been thinking of something like this. Maybe he wasn't saying that bugs shouldn't exist, but rather that they should be addressed before other things or marked as won't fix.



                Here is an excerpt from the article The Joel Test: 12 Steps to Better Code:




                Do you fix bugs before writing new code?



                The very first version of Microsoft Word for Windows was considered a "death march" project. It
                took forever. It kept slipping. The whole team was working ridiculous
                hours, the project was delayed again, and again, and again, and the
                stress was incredible. When the dang thing finally shipped, years
                late, Microsoft sent the whole team off to Cancun for a vacation, then
                sat down for some serious soul-searching.



                What they realized was that the project managers had been so insistent
                on keeping to the "schedule" that programmers simply rushed through
                the coding process, writing extremely bad code, because the bug fixing
                phase was not a part of the formal schedule. There was no attempt to
                keep the bug-count down. Quite the opposite. The story goes that one
                programmer, who had to write the code to calculate the height of a
                line of text, simply wrote "return 12;" and waited for the bug report
                to come in about how his function is not always correct. The schedule
                was merely a checklist of features waiting to be turned into bugs. In
                the post-mortem, this was referred to as "infinite defects
                methodology".



                To correct the problem, Microsoft universally adopted something called
                a "zero defects methodology". Many of the programmers in the company
                giggled, since it sounded like management thought they could reduce
                the bug count by executive fiat. Actually, "zero defects" meant that
                at any given time, the highest priority is to eliminate bugs before
                writing any new code. Here's why.



                In general, the longer you wait before fixing a bug, the costlier (in
                time and money) it is to fix.



                For example, when you make a typo or syntax error that the compiler
                catches, fixing it is basically trivial.



                When you have a bug in your code that you see the first time you try
                to run it, you will be able to fix it in no time at all, because all
                the code is still fresh in your mind.



                If you find a bug in some code that you wrote a few days ago, it will
                take you a while to hunt it down, but when you reread the code you
                wrote, you'll remember everything and you'll be able to fix the bug in
                a reasonable amount of time.



                But if you find a bug in code that you wrote a few months ago, you'll
                probably have forgotten a lot of things about that code, and it's much
                harder to fix. By that time you may be fixing somebody else's code,
                and they may be in Aruba on vacation, in which case, fixing the bug is
                like science: you have to be slow, methodical, and meticulous, and you
                can't be sure how long it will take to discover the cure.



                And if you find a bug in code that has already shipped, you're going
                to incur incredible expense getting it fixed.



                That's one reason to fix bugs right away: because it takes less time.
                There's another reason, which relates to the fact that it's easier to
                predict how long it will take to write new code than to fix an
                existing bug. For example, if I asked you to predict how long it would
                take to write the code to sort a list, you could give me a pretty good
                estimate. But if I asked you how to predict how long it would take to
                fix that bug where your code doesn't work if Internet Explorer 5.5 is
                installed, you can't even guess, because you don't know (by
                definition) what's causing the bug. It could take 3 days to track it
                down, or it could take 2 minutes.



                What this means is that if you have a schedule with a lot of bugs
                remaining to be fixed, the schedule is unreliable. But if you've fixed
                all the known bugs, and all that's left is new code, then your
                schedule will be stunningly more accurate.



                Another great thing about keeping the bug count at zero is that you
                can respond much faster to competition. Some programmers think of this
                as keeping the product ready to ship at all times. Then if your
                competitor introduces a killer new feature that is stealing your
                customers, you can implement just that feature and ship on the spot,
                without having to fix a large number of accumulated bugs.




                Source






                share|improve this answer





















                • Microsoft is not really a shinning example for a company that does not have a truckload of bugs.
                  – Rui F Ribeiro
                  Jun 30 '16 at 16:02














                up vote
                6
                down vote













                Joe Spolsky has an interesting article referring to Microsoft's "zero defects methodology". I wonder if your non-technical manager may have been thinking of something like this. Maybe he wasn't saying that bugs shouldn't exist, but rather that they should be addressed before other things or marked as won't fix.



                Here is an excerpt from the article The Joel Test: 12 Steps to Better Code:




                Do you fix bugs before writing new code?



                The very first version of Microsoft Word for Windows was considered a "death march" project. It
                took forever. It kept slipping. The whole team was working ridiculous
                hours, the project was delayed again, and again, and again, and the
                stress was incredible. When the dang thing finally shipped, years
                late, Microsoft sent the whole team off to Cancun for a vacation, then
                sat down for some serious soul-searching.



                What they realized was that the project managers had been so insistent
                on keeping to the "schedule" that programmers simply rushed through
                the coding process, writing extremely bad code, because the bug fixing
                phase was not a part of the formal schedule. There was no attempt to
                keep the bug-count down. Quite the opposite. The story goes that one
                programmer, who had to write the code to calculate the height of a
                line of text, simply wrote "return 12;" and waited for the bug report
                to come in about how his function is not always correct. The schedule
                was merely a checklist of features waiting to be turned into bugs. In
                the post-mortem, this was referred to as "infinite defects
                methodology".



                To correct the problem, Microsoft universally adopted something called
                a "zero defects methodology". Many of the programmers in the company
                giggled, since it sounded like management thought they could reduce
                the bug count by executive fiat. Actually, "zero defects" meant that
                at any given time, the highest priority is to eliminate bugs before
                writing any new code. Here's why.



                In general, the longer you wait before fixing a bug, the costlier (in
                time and money) it is to fix.



                For example, when you make a typo or syntax error that the compiler
                catches, fixing it is basically trivial.



                When you have a bug in your code that you see the first time you try
                to run it, you will be able to fix it in no time at all, because all
                the code is still fresh in your mind.



                If you find a bug in some code that you wrote a few days ago, it will
                take you a while to hunt it down, but when you reread the code you
                wrote, you'll remember everything and you'll be able to fix the bug in
                a reasonable amount of time.



                But if you find a bug in code that you wrote a few months ago, you'll
                probably have forgotten a lot of things about that code, and it's much
                harder to fix. By that time you may be fixing somebody else's code,
                and they may be in Aruba on vacation, in which case, fixing the bug is
                like science: you have to be slow, methodical, and meticulous, and you
                can't be sure how long it will take to discover the cure.



                And if you find a bug in code that has already shipped, you're going
                to incur incredible expense getting it fixed.



                That's one reason to fix bugs right away: because it takes less time.
                There's another reason, which relates to the fact that it's easier to
                predict how long it will take to write new code than to fix an
                existing bug. For example, if I asked you to predict how long it would
                take to write the code to sort a list, you could give me a pretty good
                estimate. But if I asked you how to predict how long it would take to
                fix that bug where your code doesn't work if Internet Explorer 5.5 is
                installed, you can't even guess, because you don't know (by
                definition) what's causing the bug. It could take 3 days to track it
                down, or it could take 2 minutes.



                What this means is that if you have a schedule with a lot of bugs
                remaining to be fixed, the schedule is unreliable. But if you've fixed
                all the known bugs, and all that's left is new code, then your
                schedule will be stunningly more accurate.



                Another great thing about keeping the bug count at zero is that you
                can respond much faster to competition. Some programmers think of this
                as keeping the product ready to ship at all times. Then if your
                competitor introduces a killer new feature that is stealing your
                customers, you can implement just that feature and ship on the spot,
                without having to fix a large number of accumulated bugs.




                Source






                share|improve this answer





















                • Microsoft is not really a shinning example for a company that does not have a truckload of bugs.
                  – Rui F Ribeiro
                  Jun 30 '16 at 16:02












                up vote
                6
                down vote










                up vote
                6
                down vote









                Joe Spolsky has an interesting article referring to Microsoft's "zero defects methodology". I wonder if your non-technical manager may have been thinking of something like this. Maybe he wasn't saying that bugs shouldn't exist, but rather that they should be addressed before other things or marked as won't fix.



                Here is an excerpt from the article The Joel Test: 12 Steps to Better Code:




                Do you fix bugs before writing new code?



                The very first version of Microsoft Word for Windows was considered a "death march" project. It
                took forever. It kept slipping. The whole team was working ridiculous
                hours, the project was delayed again, and again, and again, and the
                stress was incredible. When the dang thing finally shipped, years
                late, Microsoft sent the whole team off to Cancun for a vacation, then
                sat down for some serious soul-searching.



                What they realized was that the project managers had been so insistent
                on keeping to the "schedule" that programmers simply rushed through
                the coding process, writing extremely bad code, because the bug fixing
                phase was not a part of the formal schedule. There was no attempt to
                keep the bug-count down. Quite the opposite. The story goes that one
                programmer, who had to write the code to calculate the height of a
                line of text, simply wrote "return 12;" and waited for the bug report
                to come in about how his function is not always correct. The schedule
                was merely a checklist of features waiting to be turned into bugs. In
                the post-mortem, this was referred to as "infinite defects
                methodology".



                To correct the problem, Microsoft universally adopted something called
                a "zero defects methodology". Many of the programmers in the company
                giggled, since it sounded like management thought they could reduce
                the bug count by executive fiat. Actually, "zero defects" meant that
                at any given time, the highest priority is to eliminate bugs before
                writing any new code. Here's why.



                In general, the longer you wait before fixing a bug, the costlier (in
                time and money) it is to fix.



                For example, when you make a typo or syntax error that the compiler
                catches, fixing it is basically trivial.



                When you have a bug in your code that you see the first time you try
                to run it, you will be able to fix it in no time at all, because all
                the code is still fresh in your mind.



                If you find a bug in some code that you wrote a few days ago, it will
                take you a while to hunt it down, but when you reread the code you
                wrote, you'll remember everything and you'll be able to fix the bug in
                a reasonable amount of time.



                But if you find a bug in code that you wrote a few months ago, you'll
                probably have forgotten a lot of things about that code, and it's much
                harder to fix. By that time you may be fixing somebody else's code,
                and they may be in Aruba on vacation, in which case, fixing the bug is
                like science: you have to be slow, methodical, and meticulous, and you
                can't be sure how long it will take to discover the cure.



                And if you find a bug in code that has already shipped, you're going
                to incur incredible expense getting it fixed.



                That's one reason to fix bugs right away: because it takes less time.
                There's another reason, which relates to the fact that it's easier to
                predict how long it will take to write new code than to fix an
                existing bug. For example, if I asked you to predict how long it would
                take to write the code to sort a list, you could give me a pretty good
                estimate. But if I asked you how to predict how long it would take to
                fix that bug where your code doesn't work if Internet Explorer 5.5 is
                installed, you can't even guess, because you don't know (by
                definition) what's causing the bug. It could take 3 days to track it
                down, or it could take 2 minutes.



                What this means is that if you have a schedule with a lot of bugs
                remaining to be fixed, the schedule is unreliable. But if you've fixed
                all the known bugs, and all that's left is new code, then your
                schedule will be stunningly more accurate.



                Another great thing about keeping the bug count at zero is that you
                can respond much faster to competition. Some programmers think of this
                as keeping the product ready to ship at all times. Then if your
                competitor introduces a killer new feature that is stealing your
                customers, you can implement just that feature and ship on the spot,
                without having to fix a large number of accumulated bugs.




                Source






                share|improve this answer













                Joe Spolsky has an interesting article referring to Microsoft's "zero defects methodology". I wonder if your non-technical manager may have been thinking of something like this. Maybe he wasn't saying that bugs shouldn't exist, but rather that they should be addressed before other things or marked as won't fix.



                Here is an excerpt from the article The Joel Test: 12 Steps to Better Code:




                Do you fix bugs before writing new code?



                The very first version of Microsoft Word for Windows was considered a "death march" project. It
                took forever. It kept slipping. The whole team was working ridiculous
                hours, the project was delayed again, and again, and again, and the
                stress was incredible. When the dang thing finally shipped, years
                late, Microsoft sent the whole team off to Cancun for a vacation, then
                sat down for some serious soul-searching.



                What they realized was that the project managers had been so insistent
                on keeping to the "schedule" that programmers simply rushed through
                the coding process, writing extremely bad code, because the bug fixing
                phase was not a part of the formal schedule. There was no attempt to
                keep the bug-count down. Quite the opposite. The story goes that one
                programmer, who had to write the code to calculate the height of a
                line of text, simply wrote "return 12;" and waited for the bug report
                to come in about how his function is not always correct. The schedule
                was merely a checklist of features waiting to be turned into bugs. In
                the post-mortem, this was referred to as "infinite defects
                methodology".



                To correct the problem, Microsoft universally adopted something called
                a "zero defects methodology". Many of the programmers in the company
                giggled, since it sounded like management thought they could reduce
                the bug count by executive fiat. Actually, "zero defects" meant that
                at any given time, the highest priority is to eliminate bugs before
                writing any new code. Here's why.



                In general, the longer you wait before fixing a bug, the costlier (in
                time and money) it is to fix.



                For example, when you make a typo or syntax error that the compiler
                catches, fixing it is basically trivial.



                When you have a bug in your code that you see the first time you try
                to run it, you will be able to fix it in no time at all, because all
                the code is still fresh in your mind.



                If you find a bug in some code that you wrote a few days ago, it will
                take you a while to hunt it down, but when you reread the code you
                wrote, you'll remember everything and you'll be able to fix the bug in
                a reasonable amount of time.



                But if you find a bug in code that you wrote a few months ago, you'll
                probably have forgotten a lot of things about that code, and it's much
                harder to fix. By that time you may be fixing somebody else's code,
                and they may be in Aruba on vacation, in which case, fixing the bug is
                like science: you have to be slow, methodical, and meticulous, and you
                can't be sure how long it will take to discover the cure.



                And if you find a bug in code that has already shipped, you're going
                to incur incredible expense getting it fixed.



                That's one reason to fix bugs right away: because it takes less time.
                There's another reason, which relates to the fact that it's easier to
                predict how long it will take to write new code than to fix an
                existing bug. For example, if I asked you to predict how long it would
                take to write the code to sort a list, you could give me a pretty good
                estimate. But if I asked you how to predict how long it would take to
                fix that bug where your code doesn't work if Internet Explorer 5.5 is
                installed, you can't even guess, because you don't know (by
                definition) what's causing the bug. It could take 3 days to track it
                down, or it could take 2 minutes.



                What this means is that if you have a schedule with a lot of bugs
                remaining to be fixed, the schedule is unreliable. But if you've fixed
                all the known bugs, and all that's left is new code, then your
                schedule will be stunningly more accurate.



                Another great thing about keeping the bug count at zero is that you
                can respond much faster to competition. Some programmers think of this
                as keeping the product ready to ship at all times. Then if your
                competitor introduces a killer new feature that is stealing your
                customers, you can implement just that feature and ship on the spot,
                without having to fix a large number of accumulated bugs.




                Source







                share|improve this answer













                share|improve this answer



                share|improve this answer











                answered Jun 30 '16 at 14:09









                sixtyfootersdude

                33816




                33816











                • Microsoft is not really a shinning example for a company that does not have a truckload of bugs.
                  – Rui F Ribeiro
                  Jun 30 '16 at 16:02
















                • Microsoft is not really a shinning example for a company that does not have a truckload of bugs.
                  – Rui F Ribeiro
                  Jun 30 '16 at 16:02















                Microsoft is not really a shinning example for a company that does not have a truckload of bugs.
                – Rui F Ribeiro
                Jun 30 '16 at 16:02




                Microsoft is not really a shinning example for a company that does not have a truckload of bugs.
                – Rui F Ribeiro
                Jun 30 '16 at 16:02










                up vote
                5
                down vote













                Is there something that the business could do to have less bugs? Maybe cleaning up technical debt? Maybe recruiting specific people to test software? Maybe less tight deadlines?



                If you would like any of those things to happen in your organisation you could bring it up when the person asks you to produce fewer bugs.






                share|improve this answer





















                • Of course you can. If the boss gives you the budget.
                  – gnasher729
                  Jun 30 '16 at 17:55










                • @gnasher729 : A likely response might be that the boss stops caring about bug-free code if you explain what reducing bugs would require. That completely works for the purposes of this exchange.
                  – Christian
                  Jun 30 '16 at 18:43















                up vote
                5
                down vote













                Is there something that the business could do to have less bugs? Maybe cleaning up technical debt? Maybe recruiting specific people to test software? Maybe less tight deadlines?



                If you would like any of those things to happen in your organisation you could bring it up when the person asks you to produce fewer bugs.






                share|improve this answer





















                • Of course you can. If the boss gives you the budget.
                  – gnasher729
                  Jun 30 '16 at 17:55










                • @gnasher729 : A likely response might be that the boss stops caring about bug-free code if you explain what reducing bugs would require. That completely works for the purposes of this exchange.
                  – Christian
                  Jun 30 '16 at 18:43













                up vote
                5
                down vote










                up vote
                5
                down vote









                Is there something that the business could do to have less bugs? Maybe cleaning up technical debt? Maybe recruiting specific people to test software? Maybe less tight deadlines?



                If you would like any of those things to happen in your organisation you could bring it up when the person asks you to produce fewer bugs.






                share|improve this answer













                Is there something that the business could do to have less bugs? Maybe cleaning up technical debt? Maybe recruiting specific people to test software? Maybe less tight deadlines?



                If you would like any of those things to happen in your organisation you could bring it up when the person asks you to produce fewer bugs.







                share|improve this answer













                share|improve this answer



                share|improve this answer











                answered Jun 30 '16 at 13:14









                Christian

                36816




                36816











                • Of course you can. If the boss gives you the budget.
                  – gnasher729
                  Jun 30 '16 at 17:55










                • @gnasher729 : A likely response might be that the boss stops caring about bug-free code if you explain what reducing bugs would require. That completely works for the purposes of this exchange.
                  – Christian
                  Jun 30 '16 at 18:43

















                • Of course you can. If the boss gives you the budget.
                  – gnasher729
                  Jun 30 '16 at 17:55










                • @gnasher729 : A likely response might be that the boss stops caring about bug-free code if you explain what reducing bugs would require. That completely works for the purposes of this exchange.
                  – Christian
                  Jun 30 '16 at 18:43
















                Of course you can. If the boss gives you the budget.
                – gnasher729
                Jun 30 '16 at 17:55




                Of course you can. If the boss gives you the budget.
                – gnasher729
                Jun 30 '16 at 17:55












                @gnasher729 : A likely response might be that the boss stops caring about bug-free code if you explain what reducing bugs would require. That completely works for the purposes of this exchange.
                – Christian
                Jun 30 '16 at 18:43





                @gnasher729 : A likely response might be that the boss stops caring about bug-free code if you explain what reducing bugs would require. That completely works for the purposes of this exchange.
                – Christian
                Jun 30 '16 at 18:43











                up vote
                0
                down vote













                Perhaps a explanation along these lines could work:



                All code rests on assumptions - which may turn out to be wrong or even start out as correct, but later become false.



                Quite often, it is assumed that user input validation is centralized, so underlying services assume their input data is valid. If someone else bypasses this central validation, bugs will be expected.



                Very few bugs are created on purpose, but rather because another developer changed code without being aware of the assumptions related to that code.



                Sadly, most code is undocumented, meaning developers need to make educated guesses regarding use. Others times, documentation exists, but only as way too long templated Word documents that typically bury the relevant stuff in tons of boilerplate. In addition, the more documentation, the less likely that is has actually been updated when the code changes.






                share|improve this answer

























                  up vote
                  0
                  down vote













                  Perhaps a explanation along these lines could work:



                  All code rests on assumptions - which may turn out to be wrong or even start out as correct, but later become false.



                  Quite often, it is assumed that user input validation is centralized, so underlying services assume their input data is valid. If someone else bypasses this central validation, bugs will be expected.



                  Very few bugs are created on purpose, but rather because another developer changed code without being aware of the assumptions related to that code.



                  Sadly, most code is undocumented, meaning developers need to make educated guesses regarding use. Others times, documentation exists, but only as way too long templated Word documents that typically bury the relevant stuff in tons of boilerplate. In addition, the more documentation, the less likely that is has actually been updated when the code changes.






                  share|improve this answer























                    up vote
                    0
                    down vote










                    up vote
                    0
                    down vote









                    Perhaps a explanation along these lines could work:



                    All code rests on assumptions - which may turn out to be wrong or even start out as correct, but later become false.



                    Quite often, it is assumed that user input validation is centralized, so underlying services assume their input data is valid. If someone else bypasses this central validation, bugs will be expected.



                    Very few bugs are created on purpose, but rather because another developer changed code without being aware of the assumptions related to that code.



                    Sadly, most code is undocumented, meaning developers need to make educated guesses regarding use. Others times, documentation exists, but only as way too long templated Word documents that typically bury the relevant stuff in tons of boilerplate. In addition, the more documentation, the less likely that is has actually been updated when the code changes.






                    share|improve this answer













                    Perhaps a explanation along these lines could work:



                    All code rests on assumptions - which may turn out to be wrong or even start out as correct, but later become false.



                    Quite often, it is assumed that user input validation is centralized, so underlying services assume their input data is valid. If someone else bypasses this central validation, bugs will be expected.



                    Very few bugs are created on purpose, but rather because another developer changed code without being aware of the assumptions related to that code.



                    Sadly, most code is undocumented, meaning developers need to make educated guesses regarding use. Others times, documentation exists, but only as way too long templated Word documents that typically bury the relevant stuff in tons of boilerplate. In addition, the more documentation, the less likely that is has actually been updated when the code changes.







                    share|improve this answer













                    share|improve this answer



                    share|improve this answer











                    answered Jun 30 '16 at 11:24









                    morsor

                    6,56921631




                    6,56921631




















                        up vote
                        0
                        down vote













                        All the other answers advice you to discuss this view point of your nontechnical manager with him/her and they somehow imply that it is possible to educate and correct him/her. They completely disregard the fact that nontechnical managers have a handicap. They tend to be complely convinced that their viewpoints, however ridiculous, are pearls of wisdom because they are ... managers. Giving them a response that goes against their preconceived notions will hurt their considerable egos and will only invite their displeasure, more scrutiny, interference and micromanagement for your team.



                        Instead give a brief response agreeing with this nontechnical genius (just nod your head if meeting in person or respond back with a brief "We will work on it right away" if by email) and promptly put the whole episode out of your mind. His ego remains intact and you can focus on your work - a win for you, your team, your customers and your company.






                        share|improve this answer

























                          up vote
                          0
                          down vote













                          All the other answers advice you to discuss this view point of your nontechnical manager with him/her and they somehow imply that it is possible to educate and correct him/her. They completely disregard the fact that nontechnical managers have a handicap. They tend to be complely convinced that their viewpoints, however ridiculous, are pearls of wisdom because they are ... managers. Giving them a response that goes against their preconceived notions will hurt their considerable egos and will only invite their displeasure, more scrutiny, interference and micromanagement for your team.



                          Instead give a brief response agreeing with this nontechnical genius (just nod your head if meeting in person or respond back with a brief "We will work on it right away" if by email) and promptly put the whole episode out of your mind. His ego remains intact and you can focus on your work - a win for you, your team, your customers and your company.






                          share|improve this answer























                            up vote
                            0
                            down vote










                            up vote
                            0
                            down vote









                            All the other answers advice you to discuss this view point of your nontechnical manager with him/her and they somehow imply that it is possible to educate and correct him/her. They completely disregard the fact that nontechnical managers have a handicap. They tend to be complely convinced that their viewpoints, however ridiculous, are pearls of wisdom because they are ... managers. Giving them a response that goes against their preconceived notions will hurt their considerable egos and will only invite their displeasure, more scrutiny, interference and micromanagement for your team.



                            Instead give a brief response agreeing with this nontechnical genius (just nod your head if meeting in person or respond back with a brief "We will work on it right away" if by email) and promptly put the whole episode out of your mind. His ego remains intact and you can focus on your work - a win for you, your team, your customers and your company.






                            share|improve this answer













                            All the other answers advice you to discuss this view point of your nontechnical manager with him/her and they somehow imply that it is possible to educate and correct him/her. They completely disregard the fact that nontechnical managers have a handicap. They tend to be complely convinced that their viewpoints, however ridiculous, are pearls of wisdom because they are ... managers. Giving them a response that goes against their preconceived notions will hurt their considerable egos and will only invite their displeasure, more scrutiny, interference and micromanagement for your team.



                            Instead give a brief response agreeing with this nontechnical genius (just nod your head if meeting in person or respond back with a brief "We will work on it right away" if by email) and promptly put the whole episode out of your mind. His ego remains intact and you can focus on your work - a win for you, your team, your customers and your company.







                            share|improve this answer













                            share|improve this answer



                            share|improve this answer











                            answered Jun 30 '16 at 15:38









                            user53392

                            91




                            91












                                Comments

                                Popular posts from this blog

                                What does second last employer means? [closed]

                                Installing NextGIS Connect into QGIS 3?

                                One-line joke