It's common practice for developers to make small "TODO" notes in code as they work for themselves or others to clarify at some time...

// TODO: confirm this business requirement...
// TODO: make this better!
// TODO: bread, butter, eggs and milk...

Issues can arise when the TODO's are not taken care of for whatever reason or get lost in the mayhem of meeting deadlines. A worst case scenario could arise when there is a production defect for an obscure situation and the maintenance programmer finds something like this:

// TODO: Not sure if there are any more response codes for this one, check before release.

Opps! Now that's expensive.
Now I am not saying this is good or bad (!) practice - but what I have started to do within my team is create either a failing or ignored unit test (depending on the importance) marking what would normally be an innocent "TODO" item. The unit test stays in the build as either a fail or ignore and does not drop off the radar.

[Test]
public void Need_to_confirm_foo()
{
  Assert.Fail();
}

Or...

[Test]
[Ignore("Confirmation required from the business")]
public void A_foo_only_has_a_bla()
{
}

It's much harder to miss a bunch of ignored or failing unit tests before that production release than some well hidden TODO comments!

 

Scott Guthrie talks about Microsoft releasing the .Net framework source code later this year.
A very good move by Microsoft I think :-)

http://weblogs.asp.net/scottgu/archive/2007/10/03/releasing-the-source-code-for-the-net-framework-libraries.aspx