In a conversation on Mastodon, Jeff Grigg wrote:
the better I understand real biology, the better I understand how absolutely horrifyingly bad its “designs” often are!
This is entirely true. I emphasized that in an introduction I cut from the final episode in the series. Here it is, to show I appreciate the problem. It’s pretty much true that this project is going to be a dance where I try to be biologically faithful while also coping with the fact that evolution is capable of dealing with far more complexity than I am.
Not long after Dawn and I married, I conceived of the idea of co-writing a paper titled, “Your body is a gross kludge, so how come it works so much better than your software?” Dawn was to provide examples of kludgy body parts and systems – of which there are many – and I would apply them to software. The same structure as most of these podcast episodes, actually.
It never happened, for two reasons:
First, academic medicine isn’t exactly a field that rewards flamboyance in the way software does, and Dawn didn’t think that title would look so great when she went up for tenure.
Second, I had a killer first line for a conference presentation – “let’s talk about urine” – but that was pretty much it. Yes, the body is kludgy, so… what?
Good software is supposed to be understandable, and that is just not a design consideration for the body. Good software is also supposed to be extensible, and the body offers very little opportunity for that. Every improvement to a hawk’s body, for example, is done via a series of total rewrites: generation after generation of hawks, each constructed anew with only minor changes.
However, that old ambition never really died, and the books I’ve been reading for this series rekindled it. The brain is as kludgy as the rest of the body, but – as an organ – it suggests more ideas than the liver or the urinary tract. I’ll explain some of those ideas in this episode. I intend to try them out in an app I’m preparing to code, one to help me write podcast scripts. In my retirement, I like to think I’m upholding one of the great traditions of programming: spending mere months of pleasurable work to save entire hours of time and frustration.