Software Engineering Parables 3: Project Xanadu

xanadu

In the 1960’s Ted Nelson inspired a generation with his papers on the future of information and his coined term ‘hypertext.’  The culmination of his thoughts became Project Xanadu.  Project Xanadu was a mixture of the World Wide Web with version control which in his eyes would solve many of the worlds woes.  His assumption was that many of the worlds problems stem from ignorance and misinformation.  It was ambitious and complete in its appraisal of the problem with exchanging and archiving information.  One killer feature that was noted was the impossibility for dead hyperlinks.  Project Xanadu had a  ~20 year head start on Tim Berners-Lee’s World Wide Web, but alas it didn’t ship in time.

This story comes to mind when in Software Engineering we are designing something and the discussion devolves into a chain of minor considerations that complicate the larger goal.  History shows us that the implementation of the web that revolutionized the world was the system that ignored versions and dead-ends, the flawed version is the one that shipped and brought immeasurable value to humanity.

References:

Software Engineering Parables 2: Archie Bunker

All in the Family
All in the Family

My next parable comes from Jesse Schell’s wonderful book “The Art of Game Design.”  In the book at some point Dr. Schell starts recounting the story of the development of the hit TV show from the 70’s, “All in the Family.”  So the show had been planned out and they filmed a pilot episode and decided to do some user testing by having some people watch the episode and asking them what they thought of the show.  After having watched the pilot episode people were pretty impressed, they liked it for the most part, except they thought that the show should would be more enjoyable without Carroll O’Conner’s character, Archie Bunker.

If you haven’t seen “All in the Family” before, Archie is the working class patriarch of the family.  He has his progressive daughter and son-in-law living with him.  They often end up in some debate where it is Archie’s old fashioned conservatism vs. his son-in-law’s progressive views.  Archie became an important vehicle for satirizing old fashioned prejudice and the show was wildly successful.  Bottom line, “All in the Family” would have been a load of shit if they listened to the feedback.  Not only that, I’ll say the world would be a worse place without Archie Bunker.

Jesse Schell provided this anecdote as the cautionary tale to balance the call to do user testing.  It is that, but also I see it as a tale that highlights the need of a vision for your work.  Had Norman Lear just been seeking to make money he would have tried to please everyone and thrown out Archie Bunker.  Fortunately for us he was in a position where he could execute his vision and make the show he wanted to make.  This was the product we fell in love with, because it didn’t dilute its raison d’etre.

Software Engineering Parables 1 : Feynman’s Biology Class

Dr. Richard Feynman c/o museumvictoria.com.au
Dr. Richard Feynman c/o museumvictoria.com.au

As software engineers we should always be on the lookout for lessons from other disciplines or from the past.  This industry is young, but also has amnesia.  Over the years I’ve clung to a few stories that resonated with me and formed my opinions on the art.  I’m going to share them in a series called Software Engineering Parables.

One book that is just chalk full of wisdom and can be a source of inspiration for anyone is the book “Surely You Must Be Joking Dr. Feynman”.  It’s an autobiography by the famous physicist Richard Feynman.  Feynman was a bit of a rebel genius who had a knack of seeing the same things as everyone else, but understanding them differently than the average Joe.

I believe the story goes that he was at Princeton, where he was studying physics.  Dr. Feynman had such a curiosity and love of learning that he would often sit-in on classes of different disciplines.  So, he picked up a class on Biology and would show up for lectures and follow along.  I don’t know if he was officially enrolled in the class (it wouldn’t surprise me if he wasn’t), but the story goes that eventually he decides to write a paper on Biology.  He feels like he has something to contribute to the field, so he gets to it and when he is done, since he has befriended some Biology majors while on campus, he decides to get one of them to proof read his paper.  The friend took it overnight then brought it back to Feynman telling him that his idea was fantastic but the paper is written all wrong, no one will take it seriously.  The friend offers to edit the paper for Feynman and to make it more inline with what is expected from a Biology paper.  Feynman agrees and in a couple of days the friend returns with the edited paper and hands it to him to read.  Feynman studied the new edited paper and he confessed that he didn’t understand it anymore, even though he was the originator of all the ideas and the original author of the paper.  The academic field of Biology expected a certain protocol on its papers, but since Feynman studied Physics he wasn’t privy.

There are so many lessons in this tiny story.  One might be that sometimes we are the authors of our own complexity.  It comes to mind today because I find that different companies have different forces at work that attribute to the level of pomp in communication.  In a startup with limited resources it is our goal to keep things simple and efficient.  At big companies, pomp is incentivized to prove your worth and intelligence.