You’ve just delivered the client update. You breathe a big sigh and lean back for a moment, then check your work queue and find it empty. Your manager wanders over, and after a bit of leisurely chat, you two agree you’ve delivered everything. And, hey, she’s looked through the code a bit and noticed that there are quite a few of these FIXME_s. "_Person," she says, "why don’t you just spend some time finishing up those FIXMEs - especially those ones that have been there for a few years in the critical paths of the production code our customers are currently relying on." …
At this point you’re either chortling, you work for Google, or you’re one month into your first real coding job (and have I got news for you …). You see,
There is no driver for fixing FIXMEs.
(I’m talking about the FIXME comments you commit, not the ones you use to keep your head straight on which tests you need to write.)
No workflow cue says, "This is where you go back and do the FIXMEs." It’s not a step in your organization’s process. Your manager generally isn’t concerned with things which have passed QA and that customers are not complaining about, and would probably rather you not touch working code without some kind of business driver, no matter how many tests cover it.
Let’s step back for a moment and think about why you want to put FIXMEs into the code. Maybe you don’t have the time to do it right, and you use an expedient method to get it done right now. Maybe you have a DRY violation that you can imagine biting you back later. Maybe you could see this creating support issues for users. Maybe you know that at some point in the future the code will need to be more general, more correct, or more efficient.
Take a close look at these reasons, adding any of your own if you have new ones. Look for a reason to add a FIXME that doesn’t come packaged with its own driver.
All the usual reasons to write “//FIXME” have their own built-in cues.
Face it, you aren’t going to fix working code, but when it breaks it won’t matter that you’ve got a neat little “//FIXME” in there. That DRY violation is here to stay until it bites you, and that’s when you better fix it or it will bite again. You won’t need the little comment when the cost benefit of fixing a user issue becomes apparent. And when the code needs to be more general, more correct, or more efficient, well, that’s when you make it so.
On those rare occasions where you have time just to improve something, what are the chances that you’ll try thinking really hard on what improvement might save you a lot of time, and you just can’t remember anything?
All those little FIXMEs create a subtle kind of tension.
It’s the same tension that David Allen talks about in Getting Things Done. Eclipse has this nice feature which tells you, “102 FIXMEs” and shows you a list. It nags at you, saying, “Your code isn’t right. There’s too much to do. You’re overwhelmed.” It puts that little red mark on the right side of the source editing window, “Here is something undone! Some coder couldn’t finish, the poor bastard!”
Remember the GTD rule: Do it, defer it, delegate it, or drop it.
And be careful that if you defer it, you do it in a realistic, actionable way. And if you are really deferring it in a realistic way - scheduling a project in the future and setting aside real time - do not put that FIXME comment in there. You may decide later that the issue is not worth the effort.
If it’s just going to nag at you, and it has its own cue anyway, for God’s sake drop it!
Last thing: This is not just about creating FIXME comments, it’s about whenever you encounter them. Whenever you encounter them - right there - on the spot. Do it, defer it, delegate it, or delete the damn thing!
