How I work with code

In Getting Things Done, David Allen discusses a work flow of how to handle things you need to-do. Now when I work at a coding task I often find places that could need some refactoring love, or needs to change in some way. There might be potential bugs, violations of DRY and all that.

What I’ve seen so far is that some developers tend to fix these “issues” as they find them, working towards a sort of zero-deficiency or a “if I cant read the code, chances are someone else wont be able to either”  motivation.

Working with code in this manner can have some interesting side-effects. To name a few.

• It takes longer to resolve a specific task
• It could result in team conflicts a some developers perceive written code as “theirs”
• It could introduce bugs, if the original intent of the code isn’t captured by tests (not even 100% code coverage will guarantee this).

What I like to do is to finish the task I’m holding as fast as possible. The reason for this is simple; others are relying on it. But while I finish the task I notice these things that needs to be changed, fixed, or clarified. Code items that require attention in someway. What I tend to do instead is to create a new Task to represent this change.

Creating a new task as several benefits.

• It allows delegation and parallel execution of code changes
• It allows the task to be discussed by the team
• It allows me as a developer to finish my current task, without having to fill up my brain with new things to-do
• It allows me to finish the task faster
• It allows the new tasks to be prioritised by the team
• It reduces the chances I need to context switch
• It allows me to work on just one task

Now or the last one I recommend reading Eric Brechners blog post about making your world easier