Early on Feathers talks about the need to change software in order to add features and fix bugs and while it is certainly necessary to make some changes to code in order to do this we discussed whether there is ever a time that we might look to keep the number of changes we’re making to a minimum. Tom suggested that if we have good enough tests then we shouldn’t be fearful of making changes at any time. I think we’d look to be more careful about making changes around the time of a release because we don’t have a lot of time to recover if we make a mistake. Perhaps that only suggests that we don’t have good enough tests though!

Something which I’ve noticed recently is that we often end up with transitionary refactorings in our code base which are attempts at refactorings which haven’t quite been completed yet. I think this is somewhat inevitable if we are making incremental changes to improve the quality of the code base. The problem with this is that it is sometimes it is not obvious where that refactoring is going and if someone other than the original authors has to work with the code then they can easily drive it in a different direction. While we were discussing this it reminded me of an idea we read in 'An agile approach to a legacy system'. The authors suggest that whenever there is a big refactoring to make the whole team only works on that until it is completed. It would be interesting to see how well this approach would work with a bigger team.

I really like the definition of unit tests that Feathers uses - tests that give us 'localised feedback and 'run fast'. I wrote a post last year where I tried to break this down further but I think Feathers' guideline is useful to keep in mind when writing these tests. It’s easy to end up relying on functional tests which undoubtably have their place but don’t provide the rapid feedback that we need to work effectively.

We also discussed the need to think twice before creating a technical debt card or adding a 'TODO' comment to a piece of code. More often than not these just end up being ignored so it makes sense to check whether you can make the change when you see the problem where possible. Evan Bottcher wrote a cool comment in a previous post I wrote where he describes his experience with TODO comments:

I think the following observation is quite astute: