May 19, 2011 at 9:16 pm
Comments posted to this topic are about the item Which Bugs Do You Find?
May 20, 2011 at 2:42 am
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.
May 20, 2011 at 2:45 am
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
----------------------------------------
May 20, 2011 at 6:38 am
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.
May 20, 2011 at 6:42 am
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.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
May 20, 2011 at 6:56 am
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
May 20, 2011 at 7:12 am
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... 😎
May 20, 2011 at 7:18 am
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 http://www.sqlservercentral.com/articles/Tally+Table/72993/.
Cross Tabs and Pivots, Part 1 – Converting Rows to Columns - http://www.sqlservercentral.com/articles/T-SQL/63681/
Cross Tabs and Pivots, Part 2 - Dynamic Cross Tabs - http://www.sqlservercentral.com/articles/Crosstab/65048/
Understanding and Using APPLY (Part 1) - http://www.sqlservercentral.com/articles/APPLY/69953/
Understanding and Using APPLY (Part 2) - http://www.sqlservercentral.com/articles/APPLY/69954/
May 20, 2011 at 7:20 am
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 http://www.sqlservercentral.com/articles/Tally+Table/72993/.
Cross Tabs and Pivots, Part 1 – Converting Rows to Columns - http://www.sqlservercentral.com/articles/T-SQL/63681/
Cross Tabs and Pivots, Part 2 - Dynamic Cross Tabs - http://www.sqlservercentral.com/articles/Crosstab/65048/
Understanding and Using APPLY (Part 1) - http://www.sqlservercentral.com/articles/APPLY/69953/
Understanding and Using APPLY (Part 2) - http://www.sqlservercentral.com/articles/APPLY/69954/
May 20, 2011 at 7:31 am
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.
May 20, 2011 at 8:29 am
Sean Lange
"the system does exactly what they asked for, unfortunately what they asked for isn't what they want".
In the distant past at a location far away an analysis of former bug complaints we came to the conclusion that what the basic problem between users / programmers & developers / managers was, as we stated it, "I think I heard what you thought you said".
We greatly reduced bug reports by producing Design specifications, that not only included what the user wanted, but equally important what was NOT wanted. The first draft of the spec (written by the programmer/developer responsible for implementing the project) was then returned to the requestor(s). The requestor(s) then had to sign, yes formally sign as accepting the specifications, in the signature blocks on the last page of the spec. In general it required three iterations of the specs to get them correct, time required/cost, less then going ahead without the approval process and then going back and "correcting bugs".
The approved specs then became the basis for the test plan, which again was a written document which proceeded through the same approval path.
A side effect of the approval process, much to our surprise, was that the user/manager and all became part of the team. It was not a "us versus them" type of relationship.
Net result, for simple/complex projects, 'bugs" reduced to near zero / none / zilch. A side benefit darn near complete documentation so as the staff changed, what was done and why it was done, was a matter of record and a "newbie" could easily become acquainted with the application from either the user or programmer point of view.
May 20, 2011 at 8:56 am
I'm often amazed at what our users manage to figure out how to do (or more often, don't remember how they managed to do it).
We run into the trouble where our application(s) have enough bits in it and grows quickly enough that no one developer knows 100% of the pieces, so there's always a worry that there will be some level of interaction that we might not know enough about.
May 20, 2011 at 9:20 am
jwhisman (5/20/2011)
(or more often, don't remember how they managed to do it).
+1 :w00t:
Ben
^ Thats me!
----------------------------------------
01010111011010000110000101110100 01100001 0110001101101111011011010111000001101100011001010111010001100101 01110100011010010110110101100101 011101110110000101110011011101000110010101110010
----------------------------------------
May 20, 2011 at 9:29 am
I've started using T-SQL Unit to create tests of assumptions about the data (since most of our data comes from 3rd party applications that I have no control over). I'm actually finding it gives me a lot of confidence...for example, if I write a stored procedure that assumes that the product code for a product exists in the product code table, I write a test that checks that there aren't any products with a product code not in the table. It's a simple thing, but running the tests periodically, I spot when a new product is added that I didn't know about or (more frequently) when a product somehow has a product code it shouldn't have.
On the other end of the spectrum, I also validate my results where I can. Typically when I build a calculation, there's a way of independently knowing if the results are within the realm I expect. E.g. I have a complex stored procedure that does a bunch of joins, filters and calculations but should return 1 result per client, I can at least verify that the # of results matches the # of clients even if I'm not validating the calculations themselves. It's not fool-proof, but at least I know nothing is advertently being dropped or multiplied in my result set, both as the data changes over time, and if I ever go back and make updates to the stored procedure.
One "bug" someone else mentioned that I do often run into is when a result is not what is expected. E.g. someone is looking for a result in a certain range, so then I start getting requests to manipulate the data (can we filter out this type of client, etc). Ugh. The best part about that is when there is staff turnover and the report is so complex that the next person doesn't understand why the report shows what it does and wants it re-built to their specifications.
Leonard
Madison, WI
May 20, 2011 at 10:08 am
I have worked for many years in Infrastructure, Data and now in QA. My observation is that most issues are a combination of three things:
- Company does not provide a project management infrastructure to oversee the process of architecting a solution, developing requirements and sincerely inspecting the product through the stages in development. This results in an unusable end product.
- End users do not carefully think through what they want before they request it and produce requirements for what it "should" do but, not what it "shouldn't" do.
- Developers are not familiar enough with the business process to know how to develop for the requirements that were not given.
What results from this combination is an end product that works only if you use it in a particular way, what we call in testing the "happy path". Any unexpected user interaction results in errors or false results. In addition, because the product is developed "in secret" without any user inspection throughout the process, the final product is an application that is unstable (generates errors at unexpected actions), unusable (the workflow is not logical), and has very little data integrity (because the range of input was not anticipated or accounted for).
So, in answer to your question, I see bugs in traditional sense of errors and improperly handled data but also in the sense of an impractical workflow. I sensed a bit of defensiveness in the previous posts from developers and this is not without consideration.
Bugs can no longer be thought of in the traditional sense as something the developer "missed". The process of development encompasses the user group, proper organization and oversight for the effort, and then finally the developers who execute the instructions adding in fixes with their range of experience working for "the customer". This must be a collaborative and ongoing effort if success will be met.
Viewing 15 posts - 1 through 15 (of 20 total)
You must be logged in to reply to this topic. Login to reply