TDD is Keyhole surgery for software
Whilst writing up an extended example of TDD, I was trying to be as incremental as possible, adding tiny little slices of behaviour all the way through the system: replace one component, get that working; show a connection established, get that working; show one field on the UI, get that working. I took the trouble to structure the changes so that the application was working nearly all the time, rather than having to rip it apart.
Before I learned how to make progress is such fine slices, I would have cracked open the whole codebase and made the changes in one sustained effort. That would have meant that I couldn’t stop until I finished, I couldn’t check in without branching, and that merging with rest of the team would be unpleasant. Lots of coders talk about this in terms of “open-heart surgery”.
So maybe keyhole surgery is a better ambition as a metaphor. All the invasive work is focussed on the part that actually matters, rather than having to open up a route to get there. It takes a little more effort, but it’s less damaging to the patients who recover much more quickly, so the procedure as a whole is safer and cheaper.
Jerry Weinberg has a post, where he writes about how “surgery” may a better term for what many software teams do than “maintenance”. It gives a better sense of the risks involved and why quick solutions implemented by juniors may not be the best approach.
Medical joke from when I shared a house with a medic. “How can you spot the laparoscopists at the pub?”, “They drink their beer through a straw.”