Hacker News new | past | comments | ask | show | jobs | submit login

Which part of the "bad code?" The actual line that failed? The code that called it which didn't check a return value? The code below it that always returned the same value regardless of success or failure? The fault in the OS that allowed a race condition because it didn't lock processes properly?

Or did the failure happen because the code that was written for an 8-bit controller is now run on a 32-bit controller and no one realized that?

Perhaps you'd want to bring in the Test Engineer who verified that the particular feature passed? Why didn't they do their job? How about the Senior QA Engineer who wrote the test cases?

Do you also want to know who wrote the Requirement that the code met? Maybe the code did exactly what the Requirements said, but the Requirement was poorly written.

Point is, failures have to be analyzed on a Systems basis. Simply looking at a line of code can be completely meaningless and miss the big picture. And yes, each of the above failures is something I've come across in my career.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: