Bug-Ception

It amazes me that people writing bug-tracking systems never seem to find all the right points to track.

At The Job, the one we have was written under the (apparent) assumption that nobody ever has more than 1 release stream, where a bug might be present in both streams, and need to be tracked as the same bug, but with different fixes (either due to schedules for the releases, or for differing code in the streams)

So we get a mess of duplicated bugs because each tester thinks of a different way to describe the bug, and can't search for the kindred bug, since it will have a different ID in the other streams

Then the process geeks came along and decided that we could keep all the releases under one bug.  Of course, that leads to total confusion about if it's been fixed in any specific stream.

Here's a tip

When you are writing a set of methods for something where you want to get the stuff compiling, but you are not looking to do full TDD, because you are worried you will forget something, then just put assert(False) in the bodies of the methods, to make sure that they will stop the system if they are run before you have the code in them.

Languages that don't have assert() can use something else - a macro that calls exit().

All you want is something that will stop things dead if you forget to fill it in.  This is better than log message or output, because you can't forget to make it work