Fix things as you go instead of letting them pile up.
I’m working on a project and keep finding things that need fixing as I move it forward. Some of them are simple, and others are more ‘ooh, that will need to be resolved before too long’.
As I keep trying to move this forward towards public testing and launch there is an ever present urge to keep going ahead. This is tempered by the other urge to fix things before they pile up. Tension. Oh yeah. It’s always fun.
As there is just me at the moment, there is no scheduling beyond my plan/goal for the day. Pick one thing and focus on that. Adding/completing something, thinking of what comes next. This is all aligned along the removing risk, working in small thin, vertical slices, and trunk-based development.
This means I can pause and fix something if I find a problem. Especially, if it needs doing, and is a simple issue. This is not always a bug. It might be that something was left unfinished. Sometimes I find that I forgot to go back and tidy something up. Best to fix it then and there, make a commit, and move on.
Bigger observations might mean setting aside time. In my case this is realising that one screen has lots of repeated code. This should be refactored out to a new method that is called as needed. This work will need more time. It will bug me until I fix it.
Teams need a fix it policy
Teams should clarify how they’ll deal with these ‘it should be fixed’ issues. If not, there is danger that everyone will ignore them as they think it’s someone else’s responsibility. This should be clarified in a team charter, or working agreement.
In my case, I know they are mine, so I do them. When I paired with someone for a bit, we did them together as we found them.
I put bigger issues into an ‘issues.md’ file in the repository. This creates a buffer for me to think about bigger issues, and means I don’t forget items either. True, some of these are process issues that are for later, but some involve other people, so need to be held back for later.
Teams should have something similar, or use ‘issues’ in GitHub to flag items too. Either of these will mean they are available to the whole team. It doesn’t matter which one is used. Just start. Change it later if you need to.
How will you apply this idea?
This post is part of a project pulling together my materials and ideas about Teaching Team Collaboration: the Human-Side of Software Development for software development to students.
If you’d like to be notified of future posts, then please sign up for more using the adjacent form. When you sign up, then I’ll send you a free copy of the collaboration rules as a PDF from the book. You can also follow me on LinkedIn
The ideas above are from my book 101+ Ideas to Improve Team Collaboration, which covers all of these little things that students can do to improve their collaboration. Also available via Kindle.