The Workplace Stack Exchange is a question and answer site for members of the workforce navigating the professional setting. It only takes a minute to sign up.
Sign up to join this community
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?
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.
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.
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)"
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.
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.
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.
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.
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.
