SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


Which Bugs Do You Find?


Which Bugs Do You Find?

Author
Message
Steve Jones
Steve Jones
SSC Guru
SSC Guru (63K reputation)SSC Guru (63K reputation)SSC Guru (63K reputation)SSC Guru (63K reputation)SSC Guru (63K reputation)SSC Guru (63K reputation)SSC Guru (63K reputation)SSC Guru (63K reputation)

Group: Administrators
Points: 63911 Visits: 19117
Comments posted to this topic are about the item Which Bugs Do You Find?

Follow me on Twitter: @way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
call.copse
call.copse
Hall of Fame
Hall of Fame (3.9K reputation)Hall of Fame (3.9K reputation)Hall of Fame (3.9K reputation)Hall of Fame (3.9K reputation)Hall of Fame (3.9K reputation)Hall of Fame (3.9K reputation)Hall of Fame (3.9K reputation)Hall of Fame (3.9K reputation)

Group: General Forum Members
Points: 3877 Visits: 1927
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.
BenWard
BenWard
Say Hey Kid
Say Hey Kid (674 reputation)Say Hey Kid (674 reputation)Say Hey Kid (674 reputation)Say Hey Kid (674 reputation)Say Hey Kid (674 reputation)Say Hey Kid (674 reputation)Say Hey Kid (674 reputation)Say Hey Kid (674 reputation)

Group: General Forum Members
Points: 674 Visits: 827
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.

Ben

^ Thats me!


----------------------------------------
01010111011010000110000101110100 01100001 0110001101101111011011010111000001101100011001010111010001100101 01110100011010010110110101100101 011101110110000101110011011101000110010101110010
----------------------------------------
smolak
smolak
SSC Rookie
SSC Rookie (32 reputation)SSC Rookie (32 reputation)SSC Rookie (32 reputation)SSC Rookie (32 reputation)SSC Rookie (32 reputation)SSC Rookie (32 reputation)SSC Rookie (32 reputation)SSC Rookie (32 reputation)

Group: General Forum Members
Points: 32 Visits: 35
I would agree with previous commenters that bugs can be classified in the following categories:

1) Process bugs
2) Data related bugs
3) Misunderstanding user requirements

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.
Eric M Russell
Eric M Russell
SSChampion
SSChampion (12K reputation)SSChampion (12K reputation)SSChampion (12K reputation)SSChampion (12K reputation)SSChampion (12K reputation)SSChampion (12K reputation)SSChampion (12K reputation)SSChampion (12K reputation)

Group: General Forum Members
Points: 12445 Visits: 10691
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.


"The universe is complicated and for the most part beyond your control, but your life is only as complicated as you choose it to be."
GSquared
GSquared
SSC-Insane
SSC-Insane (23K reputation)SSC-Insane (23K reputation)SSC-Insane (23K reputation)SSC-Insane (23K reputation)SSC-Insane (23K reputation)SSC-Insane (23K reputation)SSC-Insane (23K reputation)SSC-Insane (23K reputation)

Group: General Forum Members
Points: 23917 Visits: 9730
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 "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread

"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
SanDroid
SanDroid
SSCommitted
SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)

Group: General Forum Members
Points: 1582 Visits: 1046
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... Cool
Sean Lange
Sean Lange
One Orange Chip
One Orange Chip (26K reputation)One Orange Chip (26K reputation)One Orange Chip (26K reputation)One Orange Chip (26K reputation)One Orange Chip (26K reputation)One Orange Chip (26K reputation)One Orange Chip (26K reputation)One Orange Chip (26K reputation)

Group: General Forum Members
Points: 26396 Visits: 17557
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".

_______________________________________________________________

Need help? Help us help you.

Read the article at http://www.sqlservercentral.com/articles/Best+Practices/61537/ for best practices on asking questions.

Need to split a string? Try Jeff Modens splitter.

Cross Tabs and Pivots, Part 1 – Converting Rows to Columns
Cross Tabs and Pivots, Part 2 - Dynamic Cross Tabs
Understanding and Using APPLY (Part 1)
Understanding and Using APPLY (Part 2)
Sean Lange
Sean Lange
One Orange Chip
One Orange Chip (26K reputation)One Orange Chip (26K reputation)One Orange Chip (26K reputation)One Orange Chip (26K reputation)One Orange Chip (26K reputation)One Orange Chip (26K reputation)One Orange Chip (26K reputation)One Orange Chip (26K reputation)

Group: General Forum Members
Points: 26396 Visits: 17557
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!!!

_______________________________________________________________

Need help? Help us help you.

Read the article at http://www.sqlservercentral.com/articles/Best+Practices/61537/ for best practices on asking questions.

Need to split a string? Try Jeff Modens splitter.

Cross Tabs and Pivots, Part 1 – Converting Rows to Columns
Cross Tabs and Pivots, Part 2 - Dynamic Cross Tabs
Understanding and Using APPLY (Part 1)
Understanding and Using APPLY (Part 2)
rharding
rharding
Forum Newbie
Forum Newbie (4 reputation)Forum Newbie (4 reputation)Forum Newbie (4 reputation)Forum Newbie (4 reputation)Forum Newbie (4 reputation)Forum Newbie (4 reputation)Forum Newbie (4 reputation)Forum Newbie (4 reputation)

Group: General Forum Members
Points: 4 Visits: 42
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.
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search