The 'window fixing' wall
On my current project we have a wall where we keep track of 'window fixing' tasks - things that people want to fix in the code base but chose to defer until a later date.
Every now and then we take what’s on the wall and prioritise it according to Fabio Pereira’s effort/pain matrix so that we know which clean up tasks will provide the greatest value to the team.
While I think it’s a nice way of getting a team understanding of technical debt I think it can lead to a couple of problems which come with most attempts at group responsibility for something.
By writing the task up on the wall we’ve effectively pushed the responsibility for keeping the code clean away from us and onto the 'team'.
It also seems to make it more acceptable to make a mess in the code because we’ve acknowledged that we’ve done that and either us or a team mate will fix it later.
In a way I suppose it’s good that people are at least conscious that they’re taking short cuts at times and we have a reasonable log of where those short cuts have been taken.
On the other hand, from my experience, when people are really motivated to fix a piece of code then they’ll find the time/way to do that whether or not it’s written up on the wall.
I think this is also a good thing even though the refactoring won’t have been prioritised by the rest of the team.
Sometimes it’s easier to go and fix something when you know what needs doing rather than deferring it and having to explain the problem to someone else later.
In summary I think the centralised wall is a good idea but not a complete replacement for people being diligent and taking care of the code base themselves.
About the author
I'm currently working on short form content at ClickHouse. I publish short 5 minute videos showing how to solve data problems on YouTube @LearnDataWithMark. I previously worked on graph analytics at Neo4j, where I also co-authored the O'Reilly Graph Algorithms Book with Amy Hodler.