March 17, 2020.
Late last year I had coffee with Keith Adams, and we ended up chatting a bunch about migrations in the context of making it easier to extend an unruly codebase. The discussion went in a bunch of directions, including chatting a bit about Building Evolutionary Architecture. One idea that Keith mentioned in that discussion has particularly stuck with me: most changes happen in the same handful of files, and those files are the most effective place to invest into quality improvement.
I believe Keith attributed this idea to Adam Tornhill’s Software Design X-Rays, where Adam refers to it as hotspotting. The suggestion is that code quality should be approached the same way you’d approach a performance optimization problem: measure what matters and prioritize changes in that vicinity. This focus on files is particularly fantastic because it captures several large categories of changes that greatly impact development productivity but are easy to miss when you rely exclusively on tools that require a deeper understanding of the software: configuration changes and testing.
This seemingly obvious idea actually conflicts a bit with what I’ve learned about making large software changes, which is that efforts meant to reduce complexity often increase complexity while they’re in-progress. Worse, they permanently increase complete if they are halted before completion without being fully reverted.
This raises the central question: when should we work the hotspots and when should we work towards completion?
You should prioritize hotspots when:
You should focus on completion when:
The big takeaway though for me is that rather than one strategy being dominant, it’s most helpful to approach each project with both options in mind and make a deliberate choice.