Hey Misko great post, and I enjoy the blog! Is it too presumptuous of me to suggest another category of bugs? How about promiscuous references, where you accidentally share a reference and some where else someone modifies your state.
Does the "wiring" category include bugs that result from wrong assumptions about libraries or frameworks you are using? This (along with failing to take into account some of the things that can happen) is perhaps my most common kind of bug.
I too think there's a category missing: accidental [1] bugs.
Race conditions, timing issues, crashes, performance problems, for example. Things that aren't essential to your program, but affect it deeply when they don't work.
I didn't manage to classify them into either of the other buckets, but maybe you have more thoughts on this?
Thanks, - Kim
[1] In the sense of the second definition here: http://en.wiktionary.org/wiki/accidental
Hey Misko great post, and I enjoy the blog! Is it too presumptuous of me to suggest another category of bugs? How about promiscuous references, where you accidentally share a reference and some where else someone modifies your state.
ReplyDeleteDoes the "wiring" category include bugs that result from wrong assumptions about libraries or frameworks you are using? This (along with failing to take into account some of the things that can happen) is perhaps my most common kind of bug.
ReplyDeleteCan you temll me how to figure out the number of bugs?
ReplyDeleteAnyway, I think this is a very good post... :)
> they don't really understand testable-code
ReplyDeleteI'd love to see a blog post with a top-10 (or top-5, or top-3, whatever) guidelines to follow to produce testable code.
I realize many of your blog posts touch on various aspects of this, but it'd be helpful to see a snapshot of the most important points.
Just do opposite of this:
ReplyDeletehttp://misko.hevery.com/2008/07/24/how-to-write-3v1l-untestable-code/
I too think there's a category missing: accidental [1] bugs.
ReplyDeleteRace conditions, timing issues, crashes, performance problems, for example. Things that aren't essential to your program, but affect it deeply when they don't work.
I didn't manage to classify them into either of the other buckets, but maybe you have more thoughts on this?
Thanks,
- Kim
[1] In the sense of the second definition here: http://en.wiktionary.org/wiki/accidental