On Refactoring

Been thinking a lot about granularity in programming languages, and the tension of common refactorings leading towards either larger or smaller volumes of code and complexity. I spotted this nice tidbit relating the cognitive process of refactoring to narrative:

Refactoring isn’t about removing code, it’s about providing coherency to your metaphors. The story you were telling has changed, and while many of the symbols will remain the same (wicked step mother, dark woods, prince) others will change (dwarves, and bramble bracket, ditched for updated concepts of self determinism and midnight balls). Code is symbol manipulation, programming is narrative construction, and refactoring is editing for sense, clarity, and pronoun agreement now that you’ve changed your protagonists gender.

Refactoring reveals purpose. Regardless of whether you are deleting redundant code or adding more code by breaking up and extracting functionality, you are always setting yourself to be ready for the next move. Refactoring treats the code as a living story — it privileges the intent to go somewhere. This flowing intent can be a particularly high maintenance activity if not tempered with a merciless focus on the end result, but the payoffs come when requirements change or testing reveals unforseen usability problems, where the functionality has to change without breaking. Interestingly enough, one of the most important basic refactorings is completely neutral on the spectrum of adding or removing complexity — rename method is so useful precisely because it contributes so much to improving the story.

On a slightly side note: Matt Webb’s original notes are a deeply challenging read, full of surprising twists, leaps of intuition, lateral thinking, and emergence.