The easiest way of justifying bad or hacky code in times where there are too many tasks and not enough time to do everything properly is by just putting a TODO next to it in which you explain how it should be. But this never means that you’ll actually go back to implement those. It’s just a heads up to your colleagues that you know that this could be written better.
Over time loads and loads of those „TODOs“ will pile up and even if you see them in the code from time to time you probably won’t start fixing them as you’re currently working on another task.
The idea is that instead of just placing a TODO like:
# TODO: remove this part after new styleguide is implemented
you should add a due date to it. So it should rather look like:
# TODO [2018-10-28]: remove this part after new styleguide is implemented
There are other ways of doing it. E.g. with using macros or defining a TODO function. But I prefer the way of just extending the way I tend to write comments with adding the due date.
In addition, there are lots of discussions on how important an expired comment should be. The Ruby implementation mentioned above will throw a runtime exception if there is an expired TODO found. But there is also an example for a compiled language implementation - in this case, Scala - that breaks the entire build if there are expired comments in the code.
In my opinion, the TODOs should rather be handled with the same importance as a deprecation warning and just be logged when either the application is started or - as we are testing at the moment - in a pre_commit hook. So that everytime you commit something a script will check all project files for expired TODOs and if it finds some of those either stop the commit (you can skip the script with the "--no-verify" flag) or just display them on the console.
More discussions regarding this topic can be found in this Reddit thread.
If you have a better idea or would like to share your solution with me let me know @nico_knoll.