Good article!

here's my 2p

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.