3 ms·

I don't agree with the author, IMO bugs are coding error, the crash or the bad behaviour coming out of it is just a symptom. Not having any symptom does not mea

by neo2006 9y ago

I don't agree with the author, IMO bugs are coding error, the crash or the bad behaviour coming out of it is just a symptom. Not having any symptom does not mean that I do not have any defect/disease, with the appropriate set of tests the doctor could find that I have a disease but with no symptoms. To come back to the auth example on simcity, the software had a coding error and the proof of it is that when the symptoms were visible (with the windows 3.1 malloc version) we needed a change in the code to fix the error. The other only category that do not fell under coding error for me is design/architecture error and Hawaii issue fell into that category and it's not bug because it do not prevent us from use the software as intendant it just make the user more error prone or not able to add feature easily or wait too long or worst, no symptom at all until you want to modify expand the software.

kulu2002 9y ago
NFRs or Non Functional Requirements are root cause of bugs in most of the cases. Functional requirements are easy to meet. It is NFR where our assumptions come into picture. As an example consider selecting improper data type to represent something. When this datatype fails to accommodate given quantity/ overflows creates the bug. But this will not happen immediately. Even such issues can easily escape rigorous testing. Check 911 outage case for that matter [1]. I think it was more than just a coding error - A bad design decision. [1] https://www.theverge.com/2014/10/20/7014705/coding-error-911-fcc-washington https://www.theverge.com/2014/10/20/7014705/coding-error-911...
- virgilp 9y ago
  > Functional requirements are easy to meet. That really depends. Coding against specs is just like walking on water: easy, if frozen :)
  - kulu2002 9y ago
    Yeah .. I mean apart from 'Functionality' these are to be taken into consideration; https://msdn.microsoft.com/en-in/library/ee658094.aspx https://msdn.microsoft.com/en-in/library/ee658094.aspx But again ... You try to make system foolproof and nature will create better fools :-D
  - neo2006 9y ago
    I coded once against h264 spec it felt like walking on water, there is always an edge case that the spec do not specify and you are not sure how to handle it.
- neo2006 9y ago
  I agree, on the functional requirements vs non functional. On most of the project that I worked on the non functional part is what hurted the most. But still, in you example in my opinion there is 2 defects, a design defects for not choosing the right data structure and coding error which is not checking the boundary or any other error and handle it properly. I can choose the most terrible data structure for a given use case but I can make a good job at handling the case with it that it will work, it won't be fast or it will use double the needed memory or more cpu... But it will function properly. On the other hand I can select the perfect data structure but do a poor job at using it and end up with bugs. My point is the 2 are different type of defects and need to be catched separately with the right set of tool for each and not mixing stuff. The tools for catching coding errors are multi level of tests, code review ... The tools for catching design errors are design review, clarifying requirements (including non functional), may be formal verification when needed...

kulu2002 9y ago

NFRs or Non Functional Requirements are root cause of bugs in most of the cases. Functional requirements are easy to meet. It is NFR where our assumptions come into picture. As an example consider selecting improper data type to represent something. When this datatype fails to accommodate given quantity/ overflows creates the bug. But this will not happen immediately. Even such issues can easily escape rigorous testing. Check 911 outage case for that matter [1]. I think it was more than just a coding error - A bad design decision. [1] https://www.theverge.com/2014/10/20/7014705/coding-error-911-fcc-washington https://www.theverge.com/2014/10/20/7014705/coding-error-911...

virgilp 9y ago
> Functional requirements are easy to meet. That really depends. Coding against specs is just like walking on water: easy, if frozen :)
- kulu2002 9y ago
  Yeah .. I mean apart from 'Functionality' these are to be taken into consideration; https://msdn.microsoft.com/en-in/library/ee658094.aspx https://msdn.microsoft.com/en-in/library/ee658094.aspx But again ... You try to make system foolproof and nature will create better fools :-D
- neo2006 9y ago
  I coded once against h264 spec it felt like walking on water, there is always an edge case that the spec do not specify and you are not sure how to handle it.
neo2006 9y ago
I agree, on the functional requirements vs non functional. On most of the project that I worked on the non functional part is what hurted the most. But still, in you example in my opinion there is 2 defects, a design defects for not choosing the right data structure and coding error which is not checking the boundary or any other error and handle it properly. I can choose the most terrible data structure for a given use case but I can make a good job at handling the case with it that it will work, it won't be fast or it will use double the needed memory or more cpu... But it will function properly. On the other hand I can select the perfect data structure but do a poor job at using it and end up with bugs. My point is the 2 are different type of defects and need to be catched separately with the right set of tool for each and not mixing stuff. The tools for catching coding errors are multi level of tests, code review ... The tools for catching design errors are design review, clarifying requirements (including non functional), may be formal verification when needed...