As much as 'turning off asserts' is the classical style, that's more to do with the design of older instrumentation than the sanity of it.
Any compiled language would fit this much better - fail at compile time. Or in interpreted-o-world, at least do it at test time.
I guess it's just lovely when deployed, working, test-passing software suddenly starts failing on a server (all servers at once, globally), because someone added a TODO a few weeks ago.
"In your production environment, set DISABLE_DO_BY=1 to disable checks."
Putting time bombs in your code, regardless of a global configuration switch, is just asking for trouble.
Some years ago I had the same idea and realized something like that with the C-Preprocessor in a C++-Codebase.
When did my Todo's expire? AFTER testing, just before a new release. With my idea of exipiring Todos I created a major pain in the butt for the team.
It would be different if some other "sort of" alarm would be raised when TODOs proliferate, but a failure in the code is not a good solution. (i.e. hook a todo checker into your contious build system, let the nightly build raise hell when there are too many todos - but do not fail the production code.)
Better to make a # DOBY annotation and modify the rake task to shame if the date passed. You could also add this metadata to the existing annotations. If you what to automate the shaming, write a guard gem to watch for these annotations.
I fail to understand how the developer getting the surprising out-of-context (with regard to what the developer is currently doing) build failure due to time-bomb-TODO-comments suddenly is expected to experience an energy burst and fix the issue right then and there. After all, the developer didn't fix the issue when the comment was written!
I think this just leads the developer to either a) delete the comment or b) increase the due date.
There is also the use case of when you can't do something because you're dependent on something else, for example you might have a workaround due to a issue in one of your dependencies. Once that's resolves, you can update to the newer version of that library, and remove your workaround.
Another idea would be to automatically create a task/bug/issue for every TODO created (which closes when the TODO is removed)
Or generate a compile warning instead of a comment. Then it will annoy you constantly, with no risk to production.
I wonder if the TODO method could dynamically generate a test case that does the same.
[1] Everything is a Polyfill: Automate Deleting Code for Front End Performance - Rachel Myers and Emily Nakashima
http://www.slideshare.net/eanakashima/everything-is-a-polyfi...
A pre-commit hook is the way to go,
* Post-commit: You'll always catch the exception, but you'll be able to commit expired TODOs
* Pre-commit: you'll have to explicitly change the expired TODOs either by removing them (irrelevant TODO, todo became todone through a refactor, etc.), or discussing a better end-date ... but either way, you're forced to address the expired TODO and not run the risk of committing expired TODOs nor not taking a test path that would miss the expired TODO exception
I just enjoy the simplicity of `echo 'remember to test the milk' >> foo/.todo`.