The multiplication of TODOs

Times to times, you must have seen in the existing code something like that

// TODO Auto-generated method stub
return null;

Great. Without knowing, you might call a method that is not implemented, and get a wonderful NPE.

I also like the

//TODO to fix later

Yeah right, it will be fixed.
Now the funny part. Let's go to the TODO tab in your IDE, and count the number of TODOs in that existing project: 890 for 320 files. An average of 3 TODOs per file. Wouhou !

Enough of ranting.

To avoid that, change your default file template, to instead of adding a TODO and return a null, throw a runtime Exception like:

throw new UnsupportedOperationException("This method is not implemented");

or even better use an explicit NotImplementedException:

throw new 
   org.apache.commons.lang.NotImplementedException("TODO");

That is first step. Now the only way to enforce that the TO DO will BE DONE, is to create the / modify the test calling that piece of code. It will fail and force you to act.

Concerning the Fix Later example, I would recommand the use of a TODO to issue tracker converter, so that item would be part of the backlog, prioritized, and eventually done in some future iterations.