by Brian Marick
A podcast about how people have applied ideas from outside software to software.
Language
🇺🇲
Publishing Since
7/19/2022
Email Addresses
1 available
Phone Numbers
0 available
March 14, 2025
<p>In 1970, Winston W. Royce published a paper “<a href="https://user.fm/files/v2-9cdb817f366dc0b103bad60e15477d84/royce-managing-1970.pdf">Managing the Development of Large Software Systems</a>.” Later authors cited it as the justification for what had come to be called the "waterfall process." Yet Royce had quite specifically described that process as one that is "simplistic" and "invites failure."</p><p>That's weird. People not only promoted a process Royce had said was inadequate, they cited him as their justification. And they ignored all the elaborations that he said would make the inadequate process adequate. </p><p>What's up with that? In this episode, I blame metaphor and the perverse affordances of diagrams.</p><p>I also suggest ways you might use metaphors and node-and-arrow diagrams in a way that avoids Royce's horrible fate.</p><p>In addition to the usual transcript, there's also a <a href="https://critical.wiki.oddly-influenced.dev/view/reading-critically/view/royce-1970">Wiki version</a>.</p><p><strong>Other sources</strong></p><ul><li>Lakoff and Johnson, <a href="https://en.wikipedia.org/wiki/Metaphors_We_Live_By">Metaphors We Live By</a>, 1980.</li><li>Laurent Bossavit, <a href="https://leanpub.com/leprechauns">The Leprechauns of Software Engineering</a>, 2014.</li><li>George A Miller, “<a href="https://labs.la.utexas.edu/gilden/files/2016/04/MagicNumberSeven-Miller1956.pdf">The Magical Number Seven, Plus or Minus Two: Some Limits on our Capacity for Processing Information</a>,” 1956.</li></ul><p><strong>Credits</strong></p><p>Dawn Marick for the picture of the fish ladder. Used with permission.</p>
February 26, 2025
<p><a href="https://en.wikipedia.org/wiki/Conceptual_metaphor">Conceptual metaphor </a>is a theory in cognitive science that claims understanding and problem-solving often (but not always) happen via systems of metaphor. I present the case for it, and also expand on the theory in the light of previous episodes on ecological and embodied cognition. </p><p>This episode is theory. The next episode will cover practice.</p><p>This is the beginning of a series roughly organized around ways of discovering where your thinking has gone astray, with an undercurrent of how techniques of literary criticism might be applied to software documents (including code). </p><p><strong>Books I drew upon</strong></p><ul><li>Andrew Ortony (ed.), <a href="https://www.goodreads.com/book/show/727824.Metaphor_and_Thought">Metaphor and Thought</a> (2/e), 1993 (four essays in particular: see the transcript).</li><li>Lakoff and Johnson, <a href="https://en.wikipedia.org/wiki/Metaphors_We_Live_By">Metaphors We Live By</a>, 1980. (I worked from the first edition; there is a second edition I haven't read.)</li></ul><p>Two of the Metaphor and Thought essays have PDFified photocopies available:</p><ul><li>Reddy's "The <a href="http://www.biolinguagem.com/ling_cog_cult/reddy_1979_conduit_metaphor.pdf">Conduit Metaphor</a> – A Case of Frame Conflict in Our Language About Language"</li><li>Lakoff's "The <a href="http://www.cogsci.ucsd.edu/~coulson/203/lakoff_ps.pdf">Contemporary Theory of Metaphor</a>"</li></ul><p><strong>Other things I referred to</strong></p><ul><li><a href="https://en.wikipedia.org/wiki/T_helper_cell">Helper T cells</a></li><li>Richard P. Gabriel's <a href="https://dreamsongs.com/">website</a></li><li><a href="https://en.wikipedia.org/wiki/Dead_metaphor">"Dead" metaphors</a></li><li>The history of "<a href="https://www.wordorigins.org/big-list-entries/balls-to-the-wall">balls to the wall</a>"</li></ul><p><strong>Credits</strong></p><p>The image of an old throttle assembly is due to <a href="https://www.wordorigins.org">WordOrigins.org</a>.</p>
December 31, 2023
<p>In this episode, I ask the question: what would a software design style inspired by ecological and embodied cognition be like? I sketch some tentative ideas. I plan to explore this further at <a href="https://nh.oddly-influenced.dev/">nh.oddly-influenced.dev</a>, a blog that will document an app I'm beginning to write. </p><p>In my implementation, I plan to use Erlang-style "<a href="https://hexdocs.pm/elixir/1.16/processes.html">processes</a>" (<a href="https://en.wikipedia.org/wiki/Actor_model">actors</a>) as the core building block. Many software design heuristics are (implicitly) intended to avoid turning the app into a <a href="http://laputan.org/mud/">Big Ball of Mud</a>. Evolution is not "interested" in the future, but rather in how to add new behaviors while minimizing their metabolic cost. That's similar to, but not the same as, "<a href="https://en.wikipedia.org/wiki/Big_O_notation">Big O</a>" efficiency, perhaps because the constant factors dominate.</p><p>The question I'd like to explore is: what would be a design style that accommodates both my need to have a feeling of intellectual control <strong>and</strong> looks toward biological plausibility to make design, refactoring, and structuring decisions?</p><p><strong>Sources</strong></p><ul><li>Andy Clark, <a href="https://www.goodreads.com/book/show/291290.Being_There"><em>Being There: Putting Brain, Body, and World Together Again</em></a>, 1997</li><li>Ray Naylor, <a href="https://www.raynayler.net/the-mountain-in-the-sea.html"><em>The Mountain in the Sea</em>,</a> 2022</li><li><a href="https://hexdocs.pm/elixir/1.16/processes.html">Erlang processes</a> (explained using <a href="https://elixir-lang.org/">Elixir</a> syntax)</li></ul><p><strong>Mentioned</strong></p><ul><li>Brian Foote and Joseph Yoder, <a href="http://laputan.org/mud/">"Big Ball of Mud"</a>, 1999</li><li><a href="https://en.wikipedia.org/wiki/Tetris">Tetris</a></li><li><a href="https://en.wikipedia.org/wiki/Illinois">Illinois</a></li><li><a href="https://en.wikipedia.org/wiki/New_Hampshire">New Hampshire</a></li></ul><p><strong>Prior work</strong><br>What I'm wanting to do is <em>something like</em> what the more extreme of the Extreme Programmers did. I'm thinking of Keith Braithwaite’s <a href="https://gojko.net/2009/02/27/thought-provoking-tdd-exercise-at-the-software-craftsmanship-conference/">“test-driven design as if you meant it” </a>(<a href="https://gojko.net/2009/08/02/tdd-as-if-you-meant-it-revisited/">also</a>, <a href="https://github.com/sf105/tdd-as-if-you-meant-it">also</a>, <a href="https://www.infoq.com/presentations/TDD-as-if-You-Meant-It/">also</a>) or Corey Haines’s “<a href="https://vimeo.com/18955165">Global Day of Code Retreat</a>” exercises (<a href="https://www.goodreads.com/book/show/21841698-understanding-the-four-rules-of-simple-design">also</a>). I mentioned those in early versions of this episode's script. They got cut, but I feel bad that I didn't acknowledge prior work. </p><p><strong>Credits</strong><br>The image is an <a href="https://en.wikipedia.org/wiki/Ophanim">Ophanim</a>. These entities (note the eyes) were <a href="https://www.biblegateway.com/passage/?search=Ezekiel%201%3A1-48%3A22&version=MSG">seen by the prophet Ezekiel</a>. They are popularly considered to be angels or something like them, and they're why the phrase "wheels within wheels" is popular. I used the phrase when describing neural activation patterns that are nested within other patterns. The image was retrieved from Wikimedia Commons and was created by user RootOfAllLight, <a href="https://creativecommons.org/licenses/by-sa/4.0">CC BY-SA 4.0</a>.</p>
Pod Engine is not affiliated with, endorsed by, or officially connected with any of the podcasts displayed on this platform. We operate independently as a podcast discovery and analytics service.
All podcast artwork, thumbnails, and content displayed on this page are the property of their respective owners and are protected by applicable copyright laws. This includes, but is not limited to, podcast cover art, episode artwork, show descriptions, episode titles, transcripts, audio snippets, and any other content originating from the podcast creators or their licensors.
We display this content under fair use principles and/or implied license for the purpose of podcast discovery, information, and commentary. We make no claim of ownership over any podcast content, artwork, or related materials shown on this platform. All trademarks, service marks, and trade names are the property of their respective owners.
While we strive to ensure all content usage is properly authorized, if you are a rights holder and believe your content is being used inappropriately or without proper authorization, please contact us immediately at [email protected] for prompt review and appropriate action, which may include content removal or proper attribution.
By accessing and using this platform, you acknowledge and agree to respect all applicable copyright laws and intellectual property rights of content owners. Any unauthorized reproduction, distribution, or commercial use of the content displayed on this platform is strictly prohibited.