Comments on: ‘//TODO’ considered harmful

By: Tungano

Tungano — Wed, 24 Jun 2009 14:18:41 +0000

Not something I am happy with, but where I work it’s a customer decision whether or not to fix a bug. They tend to leave bugs in knowingly, or refuse to accept their existence because it’s not directly visible to them.
“We roughly loose 0.0001 percent in sales due to this bug, which costs such and such to fix”, conclusion -> it’s not worth it to fix.
With the stinking code remaining to sit there and considering ‘the code is the documentation’ leaving at least some markers around for the next unwary maintenance developer to run into it, is somewhat like “be aware, unpaved road ahead” or “don’t take a left the next turn or you’ll drop down a big whooping crater”.

By: Scot Mcphee

Scot Mcphee — Wed, 24 Jun 2009 13:59:25 +0000

“Typically the bug was already there and should have already -been- handled before running into it (again and again)”

Well, again, I have to say: what’s stopping your from fixing it now or any one of those other times. In other words, at one extreme you’re just accepting a situation that’s second-best, and at the other extreme, you’re collaborating in making the problem worse.

By: Tungano

Tungano — Wed, 24 Jun 2009 13:46:21 +0000

When programming in a flow it can be very interrupting having to stop work and go to an issue tracker or backlog to insert and document the issue.
The ‘quick notes’ you do there typically never get put in sprint by the customer anyhow since they don’t understand what’s been written.
Leaving something behind at least lets you stay focused on what the customer -does- find important.
Typically the bug was already there and should have already -been- handled before running into it (again and again). Often the NOTE or TODO is additional to an bug item already existant somewhere deep down on the backlog, the section that never sees the light of day.
At least now you leave a sign behind which can be complimentary or help when you -do- try a real effort for the customer to take notice of the ‘under the hood’ issue.

By: Scot Mcphee

Scot Mcphee — Mon, 08 Jun 2009 20:26:56 +0000

“I didn’t have time to do it” just mean your environment is deciding that code quality is not important enough.

“Those are all external to the code” that’s true enough as it is, but they are not external to visibility, and to other members of the team not currently reading the file containing the ‘//TODO’. My point still stands;

1. real future work due to owner requirement (backlog)

2. definite refactoring needed (fix it then and there)

3. bug (fix it then and there, or file a bug).

4. “enhancement” required later (YAGNI).

By: Dave

Dave — Mon, 08 Jun 2009 18:14:45 +0000

There’s nothing broken about leaving a reminder to yourself or another team member. Are there other ways to leave reminders? Sure; create something in an issue tracker, “write a story”, and so on. Those are all external to the code.

Undisciplined use of “TODO” is bad, just like anything else. But if I’m in flow a “TODO” (or “FIXME” or whatever) captures all I need to know, quickly and efficiently, doesn’t add significant cognitive overhead/disruption, and can be trivially returned to.

By: John Doe

John Doe — Mon, 08 Jun 2009 16:40:22 +0000

Usually TODO means will be done when I’m gone, I was aware of it but I didn’t have time to do it.

By: Bruce Goldstein

Bruce Goldstein — Mon, 08 Jun 2009 16:22:52 +0000

I totally agree. When I see lots of //To Dos in a code base I know it is not well maintained. The number of these artifacts always goes up and never down and no one ever fixes them at a future \meeting\ or such as they just get lost. If you need to mark code then simply say in your bug report or story which project, file and line number. This is just as good and keeps the info with the bug which is where it should be. Note that I use java and have read lots of source code and I do not see a lot of //To Do s there.

By: Scot Mcphee

Scot Mcphee — Sun, 07 Jun 2009 23:33:09 +0000

There are certain times when code quality does take a backseat to how fast a deliverable can be produced. Usually this is a sign of poor management.

The last sentence is I think the key one. Management that doesn’t value engineering practices is very frustrating to work with. It’s lucky I guess that we don’t generally make anything like bridges or nuclear power stations where poor engineering can easily kill someone. However I believe this complacency on the part of management needs to be challenged by developers if it’s ever to be overcome.

By: Scot Mcphee

Scot Mcphee — Sun, 07 Jun 2009 23:20:56 +0000

There are certain times when code quality does take a backseat to how fast a deliverable can be produced. Usually this is a sign of poor management.

Kevin, yes, the last sentence is the key about poor management. It possible to enlighten them (my commiserations if you’ve tried and failed). In my mind it’s a symptom that the engineering practices of the engineers you’ve employed aren’t valued by their managers. It’s lucky we’re not building bridges or nuclear power stations or anything that could kill someone as a result of its poor engineering I suppose.

By: Kevin

Kevin — Sun, 07 Jun 2009 22:59:18 +0000

Ideally, this is a really good idea and developers should take note. Why add a TODO comment, when you can just do it right away and get it over with?

Back to reality… Working in small shops (less than 5 developers) with extremely short time-lines, limited resources, and juggling multiple projects on a daily basis, it’s a fantasy to expect 100% of the code that will be produced is up to standards. There are certain times when code quality does take a backseat to how fast a deliverable can be produced. Usually this is a sign of poor management.