May 20, 2011 at 10:16 am
bugslayer (5/20/2011)
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).
After reading that you have to wonder how SONY, MS, NINTENDO, or SEGA every developed/tested/released a game console that worked.
My point is, there is a "happy path" for products developed "in secret".
It is very differant from the Extreme development or Process driven development project paths most are a part of in Business IT development.
However products are created and released everyday that where developed in secret and work.:-P
May 20, 2011 at 11:35 am
In my last position we had a number of bugs due to all sorts of reasons. Scope creep (more like scope sprint). Poorly defined requirements. Inexperienced off-shore developers (due to high turnover). A corporate mentality that it was more important to get it done now than to get it done right.'
I know we had threading issues on the clients. Possibly also memory issues but I wouldn't have been involved in that. DB performance issues because a .Net developer wrote a query against a large, unindexed column when there was a perfectly good column on the joined table.
And we had a number that bridged both .Net and the DB. Getting back to what Steve brought up we had what we referred to as "design bugs" where either the design hadn't specified a behavior so the developer made it up or the design was flat out wrong with how that part of the code should function most likely due to other change that had happened around it.
May 20, 2011 at 3:04 pm
I definitely think the types of bugs seen these days are more commonly with usability and business logic or flow.
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
May 20, 2011 at 8:31 pm
WOW, very good question/poll! I think the bugs I encounter these days are more mixture of both types.
Rod
May 25, 2011 at 8:39 am
smolak (5/20/2011)
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.
I think this classifies rather as a misunderstanding of user requirements than a bug.
I am not a completely non technical person, have read up the ideas of ribbon and can amend the ribbon. I still do not like it.
brgds
Philipp Post
June 2, 2011 at 12:50 pm
Most errors I run into are due to one or more of the following:
1)
Failure to make use of affordable data-quality defense-in-depth
approaches. Data value constraints were never defined or never enforced in the database as database constraints, triggers or views. Each data storage unit (be it a table or an xml file) should have one and only one gatekeeper unit of code that all other programs have to use in order to change that data storage unit. That way, at least all the programs that change the data storage unit agree on the rules, right or wrong. (Design Flaws)
Using just the above two features can quickly and cheaply reduce 90% of the data value errors in an application because the programmer gets hit with the error before the software is deployed to production.
2)
A complete and thorough cluelessness about database transaction design. A correct database transaction approach avoids PDC (Partial Data Cr*p) situations which are painful to debug and correct. (Design and/or Coding Flaw)
3)
Failure to handle all easily determined use cases using the requirements that were known to the designers. The use of Decision Tables with known requirements will force recognition of many possible use cases. This may cause a change in requirements before coding occurs (a good thing) or provide correct specs to the programmers. (Design Flaw)
4)
Poor database design, particularly with regards to changes in data over time. "Current" data tables will be mixed with "Historical" data tables without an understanding of the implications of changes over time. (Design Flaw)
5)
Items are not clearly and consistently named or provided with usage instructions and/or definitions. (Design Flaw)
Viewing 6 posts - 16 through 20 (of 20 total)
You must be logged in to reply to this topic. Login to reply