I'm experienced enough to not get many what I would call 'real' bugs in my applications, of course there are a few. In general these now seem to come in a two classes.

1) What I would call process bugs come from a scenario like user X presses shift tab in field Y and then presses enter before completing the date in field Z, which no-one had tried out in testing and it breaks some validation - perhaps in a particular browser.

2) Data related bugs where if particular (unexepected) values are entered or uploaded then maybe a divide by zero or something can occur - it seems hard to prevent this possibility however much you think things through and how much you test.

If it does not work how the user expects or wants I call that a problem (or 'solution staring point' in one of my past employers client facing patter!) rather than a bug. However I would agree that bug fixing has changed significantly since I started programming - perhaps doubly so since I do not really do Winforms work much these days, with fairly different problems to the web.

At the moment I write mostly management information reports and perform statistical analysis on a 3rd party's database.

The 'bugs' I come across most of the time revolve around user requirements. I very rarely come across a problem like an unhandled divide overflow or the like in this line as the majority of the complex code I write is in T-SQL queries where it's really easy to handle that sort of error. I occassionally dabble with C++ and do a lot in PHP but even then the worst sort of bug I get is accidentally typing = instead of ==

Where we have problems, is that users don't really know what they want. They ask for a report of quotations issued, compared against sales made, with a calculated % conversion rate.

We give them this and they complain that the conversion rate is too low and they want to report a higher figure up the line to the next boss! so they change the requirement and say, only count 1 quote per customer. Then they want to introduce more and more sneaky little changes to the calculation so that the numbers look better and better. So I have to do a lot of re-work, on things that the users would consider bugs (it doesnt say what they want it to say) that aren't really bugs, just users changing their mind.

Then we get problems because the database we report from is part of a 3rd party application, when they release updates, changes etc they sometimes break our reports because product ABC is no longer the only product to use type code XYZ etc. These issues are probably the worst ones we get because sometimes it takes the business weeks to notice that the numbers look 'odd'.

So from my point of view, the sort of 'bugs' we get today are not the same as the bugs we got 10+ years ago. In reality we dont get 'bugs' any more at all, computers 99.99% of the time behave as intended by the programmer, what we have, are issues. Users have issues because they cant make the computer do what THEY want.

This is for many different reasons, often because they try to use a program for something for which it was not designed or because they dont explain their requirements - or more importantly - the business analyst or analyst programmer didnt do their job properly. A programmer can only code what his/her functional spec tells them to, if this document is missing some details, if it is given to them before the business have read it and signed it off or if it doesnt exist at all, the developer will have a greatly reduced chance of successfully coding an application that meets the business' real needs.

I don't believe that "the lack of understanding in how the user will interact with functionality" could be classified as a bug. If that were the case, then many nontechnical people would consider the Office 2007 ribbon as a bug. Many people that I know still have trouble understanding how to productively use the ribbon and have refused to upgrade from Office 2003 or have switched to Open Office in order to avoid the Office ribbon.

If the users don't understand how to use the functionality, then the "bug" is probably in the documentation and/or user training (or lack thereof) and not the code itself.

I guess it depends on how you define a bug. If an application or database functions within the parameters defined by the requirements, then it has no bugs; even if the end users are unhappy with it and want something changed. Sometimes technical requirements attempt to describe something in words, when a case use diagram, mockup report, or screenshot would do a better job of documenting each step in the process and expected end result.

I've spent a lot of time recently fixing bugs caused by a prior database dev who didn't actually understand SQL as well as he thought.

For example, an insert that had to go into two tables, where the first table holds part of the data and generates an ID value, and the second table needs that ID to FK back to the first one, and holds a different portion of the data. (Oddly enough, these tables were built to have a 1:1 relationship, and all columns were mandatory in both tables, so it could/should have been one table in the first place, but that's a different story.)

The way he implemented getting the ID value from the first table was selecting the Max() value for the ID where the e-mail address matched the input value for that column. Not Scope_Identity, not an Output clause (despite being in SQL 2005 from inception on this database), selecting the Max(ID) where Email = @Email. He never anticipated the fact that not every entry would have an e-mail address, and thus the parameter would be NULL, and would not assign a value. So, in cases where there was no e-mail address provided, NOTHING would be inserted into the second table. No error message for a failed insert, no alerts to the affected department personnel, just a completely silent failure to insert into the second table.

Thousands of rows of data, important to multiple departments, rendered useless over a period of 3 years, because he didn't know about Scope_Identity and related methods.

There was another, similar bug, again caused by ignorance of T-SQL, that was intermittently inverting the legal opt-in/out options on various things. No way to tell how many records are wrong, but it's probably again in the thousands.

Another one lost an indeterminate number of records of people requesting information from the company. Based on the way it was written, it could have lost only a few, or it could have lost 10s of thousands, and we'll never know, because the data was never inserted anywhere, it just went from the web app to nowhere at all, depending on some of the input values. Again, basics of SQL (in this case, ANSI and T-SQL rules were violated) would have prevented the data loss.

I agree with the other persons that have posted and stated that today Code Projects have application requirements, end user requirements by roles, programing bugs, and end user issues.

With todays available tools you can and should always test for and resolve pre-release any issues with application requirements, end user requirements by roles, and programing bugs.

I have never worked anywhere that called or considered an end user workflow issue a bug.This includes any misunderstood application workflow issues. These have always been considered a missed or new requirement for a new feature.

Deffinately had my share of issues with poor memory management and/or data typing back in the day. IMHO: Everyone that used a first or second generation abstraction language did.

Now with the programing languages, massive amounts of cheap physical memory for use, solid definitions for data types that are portable across platforms and languages, etc... the Bug's of yesterday have turned into the IT equivalent of Polio or the Black Plague.

However we still have our issues. As systems become more open, interconnected, and protable the "NEW BUGS" are more about the security of an application or system is from external unwanted interferance or influence. How safe is your code, application, production systems from being affected by an unwanted third party influence?

Sure we still have code annoyances that can be resolved by patches and updates, those will always occur.But there was a time, and there will be again, where everything we do and how we do it will have to be changed before what is broken can be reparied.

Just ask SONY how close we are to that time again.... Recently they had a real good taste of things to come...

We have the occasional bug (where something actually doesn't do what is it supposed to do) but most of the time it is changing requirements. I can't begin to count the number of times I have entered something into our tracking system along the lines of "the system does exactly what they asked for, unfortunately what they asked for isn't what they want".

GSquared (5/20/2011)I've spent a lot of time recently fixing bugs caused by a prior database dev who didn't actually understand SQL as well as he thought.

For example, an insert that had to go into two tables, where the first table holds part of the data and generates an ID value, and the second table needs that ID to FK back to the first one, and holds a different portion of the data. (Oddly enough, these tables were built to have a 1:1 relationship, and all columns were mandatory in both tables, so it could/should have been one table in the first place, but that's a different story.)

The way he implemented getting the ID value from the first table was selecting the Max() value for the ID where the e-mail address matched the input value for that column. Not Scope_Identity, not an Output clause (despite being in SQL 2005 from inception on this database), selecting the Max(ID) where Email = @Email. He never anticipated the fact that not every entry would have an e-mail address, and thus the parameter would be NULL, and would not assign a value. So, in cases where there was no e-mail address provided, NOTHING would be inserted into the second table. No error message for a failed insert, no alerts to the affected department personnel, just a completely silent failure to insert into the second table.

Thousands of rows of data, important to multiple departments, rendered useless over a period of 3 years, because he didn't know about Scope_Identity and related methods.

There was another, similar bug, again caused by ignorance of T-SQL, that was intermittently inverting the legal opt-in/out options on various things. No way to tell how many records are wrong, but it's probably again in the thousands.

Another one lost an indeterminate number of records of people requesting information from the company. Based on the way it was written, it could have lost only a few, or it could have lost 10s of thousands, and we'll never know, because the data was never inserted anywhere, it just went from the web app to nowhere at all, depending on some of the input values. Again, basics of SQL (in this case, ANSI and T-SQL rules were violated) would have prevented the data loss.

So, that's the kind of bug I'm dealing with right now.

Gus I don't envy you on that one. I have been in a situation like that in the past and it was a tough road to unravel all the horrible stuff left behind. Some of that garbage can hide for a long time until you find it. Drinking helps!!!

Every programmer has his own way of classifying problems. They are usually different from how our boss classifies it, which is also different from how the end-user classifies it.

Applications have gone from simple data entry and straight forward report generation in the 1960s to complex interactive systems (not applications anymore). Along the way the software infrastructure which controls the applications/systems has improved to an amazing degree to help the programmer avoid or handle certain problems automatically. We programmers should be very thankful to those other programmers that were smart enough to make those improvements to the underlying software. However, there is still much that can be done.

No one causes bugs on purpose. S*** happens even in the most rigorously tested application/system.

None of this however makes programming any easier for the programmer. We have simply traded certain old bugs for new bugs. There will always be bugs. Bugs are nothing more than a problem hiding from a solution.