Dropping the hacker mentality.
A post from the OSAF mailing-list gives a summary of good practices for developers. Most of them are good, but like all long lists, some are harder to agree with. An in particular:
Rather than put a bug in the bug database, first try to fix it.
This is a bad idea and typical of a hacker's mentality as opposed to that of a software engineer. This kind of action is based on the fallacy that the scope of a bug is limited to its fix. This is the sure way to disaster (or at least to a very messy project).
If you find a bug, the first thing you should do is enter it in the bug database. The reason is simply that you are not going to be the only one working on it. Once you (or someone else) are done fixing it, it needs to be QA'ed, which may involve writing new tests. Then you might have to change the documentation, either as a release note or as a new section in your manual. Then you might have to issue a patch, or one day somebody might read your code, stumble upon your fix and short of having a reference, will wonder why the hell is going on there (here is another good practice: when you fix a bug, try to include the reference to the bug database in a comment).
Stop thinking like a hacker or all you will produce will be code used by hackers.
[Otaku, Cedric's weblog]
Agreed. Even better would be...
Then you'll be able to both cross reference the bug information with the unit test case and then when the bug gets fixed you'll have a permanent unit test to ensure the bug never comes back.
