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
One of the purposes of automatically tested code should be that this shouldn’t be an issue. But I agree in principle with the statement that a issue should be raised and reported. But this should really be done independent of the task being completed at that time. By raising the issue you can discuss the reason for the problem arising in the first place with the team and you can better keep track of how time is spent. By the latter I don’t mean that you should count minutes, but more get an overview of which tasks has been addressed.
But then we come to the question of fixing or not fixing. Having become even more of a believer in Lean Software Development I cannot help becoming troubled of the idea of keeping track of bugs and problems instead of fixing them. Keeping problems on a queue is not preventing the same type of problem arising again and again.
Yes, you should differ between bugs and “ugly code in need of refactoring” but unreadable code can also be seen as a risk and an impediment for improvement. Well worth discussing, though, and that is perhaps the most important challenge for a team. Knowing how to handle this question.
As described in Getting Things Done, you often get new ideas as your current idea is reflected back to you. Tracking these ideas, you can build on them and produce new ones. Now if you have to solve a specific task, you can finish that task, but still have a set of ideas or new knowledge about the design or even in the case of Lean software development need to stop the line.
Now the purpose of “keeping track of issues”, or incidents if that is better word, is to quickly finish the task so it can be tested and accessed by others relying on it. Most of these incidents are thrown out, and not kept track of. Or solved at within two minutes after the original task is solved. These are not issues on the user scale but questions raised during the development.
Once you have a working skeleton at place you can go back and fix “the issues” that are clearly visible to all. And especially those that were missed during automated testing. But also get new ideas, that might be better solutions to the given problem. “Ugly code in need of refactoring” is subjective, and should be handled with care. Not refactored on the fly, in a Lean pespective, “Ugly code in need of refactoring” requires a stop the line, in order to raise the issue. The line stop might infact result in the response that it is not changed, since noone has a better idea at the time.
Automated tests assist in refactoring. They do not prevent you from the need of refactoring, nor do they automatically imply good design. Automated tests are not a silverbullt for building quality software.
The core benefit here is ofcouse focus for the developer.