And now for something completely different...

   Okay, maybe not completely different, as it will still be code-related.  But, coding time is at quite a premium right now.  So, until I manage to get some time to sit down and code for fun, I'm just going to post little snippets of advice. 

   I'm working on a team with some newer developers -- just a few years under each belt, versus my decades.  One advantage, as far as this blog goes, is that it lets me spot times when they make newbie-ish mistakes that I've since learned solutions to.  Then I can share those solutions with you!  (And of course my colleagues.)

   The first one is to keep track of work not-yet-done, or klugily done in a way that should be fixed ASAP. 

   On one of the programs we're working on now, there's a part that counts down "3, 2, 1" in some particular (human) language, depending on the "content set" it's using.  (As you may recall, I'm now working for Rosetta Stone.)  We got a bug report that this was always in Spanish, even if the content set it was dealing with was in French, English, etc.  Turns out this wasn't so much a bug per se, as an unimplemented feature -- or rather a chain of unimplemented features. 

   It turns out that the guy who originally wrote the program did not know how to make Part A (which knows all about the content set) tell Part B anything.  So, he hardcoded a bunch of things, such as that Part B should launch Part C (which does the countdown) in Spanish.

   Since he's fairly new, I can't fault him too much for not knowing how to do something.  I had to Google it myself.  I can fault him for not trying to find out, though!  Over on my other blog (personal excellence blog Dare2XL), I have an old post about asking for help.  But that's only part of the story -- the non-coding part, and this is my coding blog.  B-)

   The other part is how to keep track of such unimplemented features, temporary kluges, etc.  How do you avoid releasing something as "done", only to get bug reports due to such things?

   What I've usually done is to mark them with "TODO" or "FIXME" comments.  When I think I've finished, I grep the code, configs, etc. for such tags.  (Use grep, not your eyeballs, even if you're using an editor that syntax-highlights those words.  Grep is much more reliable -- and when combinded with find or ls -R, it's much more certain to find all the relevant files.)

   Some of them are about ideas for future features, so I use a colon, and those I mark as "TODO MAYBE:" or "TODO LATER:", rather than simple "TODO:".  Note how the colon is now not next to TODO, so I can grep for "TODO:", not just "TODO".

   Another way is to use your issue-tracker (such as Bugzilla, Jira, Trac, etc.) to make small tickets for yourself for each such feature.  The effectiveness of this approach depends on many factors, such as your team's policy on making tickets, your tool's complexity, and its filtering ability.  If you can easily make tickets that come quickly to your attention without getting in other people's way, great.  If not, you can still use a private task list, be it in some purpose-built tool, a spreadsheet, a simple text file, or whatever -- just so long as you refer to it often.  (I won't go into tons of advice on how to use a task list; surely there are gazillions of web pages on that.  That said, though, Google "Getting Things Done" for one very good approach.)

   Yet another way is to make sure that the requirement is covered by a test.  (Our group is not doing much developer-level testing right now; I intend to fix that.)  In this case, there could have been a test like "Make sure that a French content set makes the countdown launch in French. Repeat for Spanish."  (Or maybe, to get broader coverage, pick two random languages each time.)

   So now, as always, dear reader, it's your turn!  How do you keep track of unfinished, or klugily finished, work, to avoid releasing it into "the wild"?  Leave a comment.