My favorite analogy for writing code is writing a book

When I want to explain the challenges of writing software I usually use writing a book as analogy (or any type of writing). 

I’ve heard and used others like building a house, but it doesn't quite cut it; the one that works almost perfectly is writing a book.

• Writing code -> Writing the book.

• Modules / Libraries / Components -> Chapters, Episodes, Paragraphs (not 1:1 relation, just an idea depending) .

• Code review -> Peer review.

• Compiling -> Putting your peer's work and assembling the book.

• Deploying -> Send it to the print, or distribute it to the libraries.

• SRE’s -> The printer guys (or who help with the printers).

• Bugs -> Errata.

• Versioning -> Editions.

• Refactoring -> Change style or re-arrange the storyline so new characters can be included in the future.

• Cloud computing ->We’re renting someone else’s printer

• Micro-services -> Now will distribute the chapters instead of the full book.

• Open source -> We can include someone else’s IP in our books to write it faster.

• Security fixes -> A bit harder to explain but somehow the book shipped with something dangerous (a razor in extreme cases) and we have to remove them from all the libraries and put the old version while we figure out how that happened

And the list goes on.

It’s fun.