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.
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
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.