Agile FAQs
  About   Slides   Home  

 
Managed Chaos
Naresh Jain's Random Thoughts on Software Development and Adventure Sports
     
`
 
RSS Feed
Recent Thoughts
Tags
Recent Comments

ToDos Gone Wild!

Writing ToDos in your code as a reminder that some needs to be fixed is almost considered as a holy grail (universal best practice) to manage technical debt. No one seems to talk about issues using ToDos.

While I’m not against ToDos, I think, in some cases developers build a tendency that:

I’ve put a ToDo, I’ve done my job and now I can move on.

I’ve a problem with this behavior. In some cases there might be tangential work that is worth marking as a ToDo, but in lot of cases what should be fixed now, gets pushed off for later. Slowly the code quality keeps dropping and technical debt sets in.

Building on this thought process, ToDos can encourage wrong behavior of not fixing stuff at the source and pushing them in the future. It’s kind of the broken window syndrome:

There are so many ToDos in this code, one more won’t make a big difference.

Even if someone wants to fix some, looking at the sheer numbers, the person can get intimidated.

Some teams have so many ToDos in their code, that the team develops immunity towards them by now (it losses its value).

So please think before adding your next ToDo.

  • http://developer-in-test.blogspot.com/ Sai

    I have faced this problem quite often, People add #fixme, #Todo, #hack spewed all over the code base. After a few days people tend to lose the context of why they added them.

    I have tried a few things like writing code to parse the project files and finding these and flag them. Adding this as part of CI process to give an idea of code quality. But my understanding is unless people take up the responsibility and become disciplined we will be stuck in this vicious circle.

  • http://developer-in-test.blogspot.com Sai

    I have faced this problem quite often, People add #fixme, #Todo, #hack spewed all over the code base. After a few days people tend to lose the context of why they added them.

    I have tried a few things like writing code to parse the project files and finding these and flag them. Adding this as part of CI process to give an idea of code quality. But my understanding is unless people take up the responsibility and become disciplined we will be stuck in this vicious circle.

  • http://www.gunish.com/ Gunish

    Isnt that quite similar to how we handel warnings in our code. ?
    I have seen code where there are huge lists of warning, and no one cares about any darn thing … and the other ones where a single warning breaks the build..

    We could create build policies in our solutions, to stop people from putting in ToDo’s  ;-)

  • http://www.gunish.com Gunish

    Isnt that quite similar to how we handel warnings in our code. ?
    I have seen code where there are huge lists of warning, and no one cares about any darn thing … and the other ones where a single warning breaks the build..

    We could create build policies in our solutions, to stop people from putting in ToDo’s  ;-)

  • Paul Boos

    Greetings Naresh!  Hope you can make teh next Agile Coach Camp!

    Anyway, hopefully folks are qualifying the to-dos; my example might be – 
    #to-do works under most conditions, but specifically know that if a 0 is entered trapping the divide zero error is not handled at this time – should be ok for now since we check the data entry that would cause this at the form 

    At least that qualification tells you 1) what teh code author knows about the potential issue (even if he doesn’t knwo teh exact problem that will occur) and his rationale for not handling it.  If you encouraged that kind of behavior, people will only put off the stuff taht shoudl be put off, just the wordiness to explain it will make them think twice. And if they still elect to put it off, then they have done a good job of explaining the issue as they know it; an important communication with teh rest of the team since someone else may have to pick up the ball and do the to-do.

    The primary purpose of the to-dos is to avoid building something that isn’t part of the current Sprint or iteration, not to push off work that truly must be done.  If folks keep that in mind, and use to-dos as a communication tool for the future, then teh problem should be avoided. 

    Cheers!
    Paul

  • Paul Boos

    Greetings Naresh!  Hope you can make teh next Agile Coach Camp!

    Anyway, hopefully folks are qualifying the to-dos; my example might be – 
    #to-do works under most conditions, but specifically know that if a 0 is entered trapping the divide zero error is not handled at this time – should be ok for now since we check the data entry that would cause this at the form 

    At least that qualification tells you 1) what teh code author knows about the potential issue (even if he doesn’t knwo teh exact problem that will occur) and his rationale for not handling it.  If you encouraged that kind of behavior, people will only put off the stuff taht shoudl be put off, just the wordiness to explain it will make them think twice. And if they still elect to put it off, then they have done a good job of explaining the issue as they know it; an important communication with teh rest of the team since someone else may have to pick up the ball and do the to-do.

    The primary purpose of the to-dos is to avoid building something that isn’t part of the current Sprint or iteration, not to push off work that truly must be done.  If folks keep that in mind, and use to-dos as a communication tool for the future, then teh problem should be avoided. 

    Cheers!
    Paul

  • http://sandeep.shetty.in/ Sandeep Shetty

    Without discipline all practices WILL become counterproductive

  • http://sandeep.shetty.in/ Sandeep Shetty

    Without discipline all practices WILL become counterproductive


    Licensed under
Creative Commons License