3 ms·

Fixing bugs versus writing new code My gut feeling is that this also depends heavily on the (technical) type of software you're writing. Dereferencing a null p

Fixing bugs versus writing new code My gut feeling is that this also depends heavily on the (technical) type of software you're writing. Dereferencing a null pointer in a C++ desktop app is a whole lot worse than a null pointer exception in a web app built on most modern frameworks. The latter normally won't take down the whole app, just show a one-off 502. A browser that crashes every 3 minutes is basically never going to cut it.

InclinedPlane 16y ago
I disagree that they are different levels of problem. A fatal error in a web app is the same as a crash, the fact that it doesn't affect other people and the fact that you can effectively "restart" the app by refreshing or going back and performing an action again is irrelevant. If you are a serious web business and your app drops a ten thousand dollar order, or it dies in the middle of posting an important live news story, or it fails to send a personal message to an SO overseas, the fact that they can retry (perhaps after re-doing a significant amount of work) is no consolation. You, dear web app creator, are still proper fucked.
- pmjordan 16y ago
  I think we can all agree that bugs are bad, but as Patrick mentioned there are different types of bugs, and some have a lower priority than new features. When I'm working with C or C++ I'm practically paranoid about bugs. [1] Memory corruption frequently has catastrophic consequences, where crashes are actually almost the best-case scenario. Bugs cause all sorts of knock-on effects in unrelated parts of the code. Most web frameworks run in a VM that avoids this kind of situation by design; moreover, state rarely lives in the app itself but is maintained in a separate database. Yep, it's still possible to accidentally DROP TABLE or DELETE/UPDATE the wrong stuff, but it's nowhere near as easy to do as a buffer overflow. I guess the modern day equivalent of memory corruption are security issues. Yet I (anecdotally) seem to encounter far fewer severe errors doing web dev. [1] to preeempt ad-hominem claims of lack of experience or skill with C/C++: they were my primary languages for around 8 years, so at least I've seen my fair share of code

InclinedPlane 16y ago

I disagree that they are different levels of problem. A fatal error in a web app is the same as a crash, the fact that it doesn't affect other people and the fact that you can effectively "restart" the app by refreshing or going back and performing an action again is irrelevant. If you are a serious web business and your app drops a ten thousand dollar order, or it dies in the middle of posting an important live news story, or it fails to send a personal message to an SO overseas, the fact that they can retry (perhaps after re-doing a significant amount of work) is no consolation. You, dear web app creator, are still proper fucked.

pmjordan 16y ago
I think we can all agree that bugs are bad, but as Patrick mentioned there are different types of bugs, and some have a lower priority than new features. When I'm working with C or C++ I'm practically paranoid about bugs. [1] Memory corruption frequently has catastrophic consequences, where crashes are actually almost the best-case scenario. Bugs cause all sorts of knock-on effects in unrelated parts of the code. Most web frameworks run in a VM that avoids this kind of situation by design; moreover, state rarely lives in the app itself but is maintained in a separate database. Yep, it's still possible to accidentally DROP TABLE or DELETE/UPDATE the wrong stuff, but it's nowhere near as easy to do as a buffer overflow. I guess the modern day equivalent of memory corruption are security issues. Yet I (anecdotally) seem to encounter far fewer severe errors doing web dev. [1] to preeempt ad-hominem claims of lack of experience or skill with C/C++: they were my primary languages for around 8 years, so at least I've seen my fair share of code