The CTO Podcast · Insights & Strategies for Chief Technology Officers Navigating the C-Suite while Balancing Technical Strategy, Team Management, & Innovation

Crafting Code and Conquering Fear: A Journey Through Middle-Earth and Conway's Law

·44 min·2 clips

Alan says fear and context change are the two common problems behind untouchable code bases.

1. The CTO Podcast episode centers on Etienne de Bruin and Alan Stewart discussing Lord of the Rings, Conway’s Law, and code quality at SyncedUp. 2. Etienne de Bruin is the host and fractional CTO, and Alan Stewart is the lead engineer whose work at SyncedUp gives the conversation a practical software context. 3. The episode asks what Conway’s Law means for team structure, outsourced development, and code that nobody wants to touch. 4. Alan explains that his interest in Tolkien began with his mother reading the books, the Rankin-Bass cartoons, and later the themes in Tolkien’s writing. 5. He describes reading the Silmarillion, the Hobbit, the Lord of the Rings, and parts of the History of Middle-earth, including the fifth volume. 6. Etienne asks why “Middle Earth” is called middle, and Alan answers that it basically means Earth in an older, archaic form. 7. Alan connects that explanation to Norse mythology and Marvel’s Thor, where “Midgard” uses the same “mid” idea. 8. The discussion then moves to Conway’s Law, which Alan attributes to programmer Melvin Conway. 9. Alan summarizes Conway’s idea as organizations producing systems that mirror their communication structures. 10. Etienne applies that idea to offshore development, shorter deadlines, and code being shaped by incentives rather than only by product goals. 11. Alan says those incentives can show up in unit testing, code duplication, and the way developers are rewarded. 12. He also says offshore teams often think in project terms and change orders, while founders expect a product-shaped code base. 13. Etienne and Alan discuss how terminology can disappear between product language and code language, which makes changes harder. 14. Alan says lack of automated tests is a major signal because developers without confidence avoid changing old code. 15. He describes untested code as something that makes developers act “as surgically as possible” and avoid refactoring. 16. Alan contrasts that with code that has tests, where teams can rewrite pieces continuously instead of waiting for a full rewrite. 17. He says collaborative structures like pair programming, mob programming, and cross-functional teams help product, testing, and operations work together. 18. The episode has an informal interview style, with long back-and-forth exchanges and a practical, reflective tone. 19. Developers, CTOs, and founders dealing with legacy code and team structure would likely get the most from it. 20. Listeners wanting a fast technical tutorial or heavy Tolkien analysis alone may skip it.

Listen to the show on

Apple Podcasts Spotify

Play clips from this episode More from The CTO Podcast