This sounds like the intro to a bad geek joke. (Answer: When it is a feature?)
But seriously, this is a valid question. Consider the following situation.
You have some code that looks like it should not work. But it does. The program is in production, for gosh sakes. Works great, every day, all day, this very feature. So you pull your hair out trying to figure how this clearly defective code does not cause a problem.
After all, one of the laws of the universe says that when something doesn’t seem right, it probably isn’t.
Usually, the cause of the “bug” turns out to be operator error, e.g. editing a stored procedure in one database, while the connection string for the web site is pointing to a different database. Or there might be multiple copies of the source code extant, and you are looking at a version different from the one that is actually running.
I was trying to track down a bug where some, but not all, automated e-mails were not getting properly sent. The error message was cryptic (although in hindsight it was perfectly clear, as is usually the case) and I was exploring all avenues. Although the problem eventually turned out to be caused by a changed password for one e-mail account, at this stage that was not at all clear.
The page which actually sends the e-mails is called ReportsPage.aspx. It is a strange beast in that it exists only as a vehicle for a CrystalReportViewer. However, the fact that CrystalReports plays a tangential role here is of no consequence. For once, the problem is not with CrystalReports.
In addition, there is an overloaded version, which accepts a Boolean that indicates if the report requires a range of dates. If true, then the script looks at specific controls on the page at runtime to get the actual start and end dates. It has the following signature:
The problem was that when I examined the source view of the page in the browser, I found that many of the calls to OpenReportsPage had an extra Boolean argument. And that did not seem to cause any problem. So was this a bug or not?
I searched my code over and over for the missing overloaded version of the function with an extra bool. As a matter of fact, I remember adding that parameter to the function a year or more ago, then removing it a short time later. But if there was no version of the function with six parameters, then why wasn’t there some sort of bad behavior?
After all, you might argue, the program runs perfectly fine and does not complain about the extra, now vestigial, arguments. Clearly, they are left over from when the function had that extra argument , and when I removed the argument from the function, I forgot to update all the calls.
In C# that would never happen because not only is it illegal, but Visual Studio will warn me and it won’t build.
I decided this was in fact a bug, because it seriously clouds the maintainability of the code. If I were actually using the extra argument, it would be a different story. But there is no place for vestigial code in any production project.