TODO comments, to some extent, make sense. Particularly if you are working iteratively (as is common in agile and TDD shops), there will be things that you recognize are going to be needed before long but which you don't want to make the detour to implement right then and there.
What gets ugly is when such comments remain in the codebase. While you are actively working on a feature it's fine to leave them in, but as soon as you get closer to completing the feature, you should focus on getting rid of them. If you don't want to go through the work of actually replacing them with proper, working code then, at least factor out the relevant functionality. To borrow @JoonasPulakka's example, where the code initially says
ConnManager.getConnection("mydatabase"); // FIXME: DB name should be configurable
you might change that to something like
with, for the time being, GetDatabaseName() being a stub that simply returns the same string that you started out with. That way, there is a clear point of future expansion, and you know that any changes made there will be reflected anywhere the database name is needed. If the database name is even moderately generic, this can be a massive improvement in maintainability.
Personally, I use a keyword of my own instead of strictly
TODO, although the intent is the same: to mark things that I know will need revisiting. Also, before I check in my code, I do a global source code search for that keyword, which is chosen such that normally it should not appear anywhere in the code. If it's found, I know I forgot something, and can go ahead and fix it.
As for including the programmer name/signature with the comment, I think that's overkill if you have a source code version control system (you do, right?). In that case, its blame feature will tell you who added the comment, or more accurately who last checked in a change that touched the comment. For example, in Visual Studio, this is easily accomplished by using the "Annotate" feature found among the source control features.