The Zen of Programming: Part Three

Speaker A: Hello and welcome to Small Batches with me, Adam Hawkins. I'm your guide to software delivery excellence. In each episode, I share a small batch of a theory and practices along the path. Topics include DevOps, Lean, Continuous Delivery and conversations with industry leaders. Now, let's begin today's episode. This episode is part three of me reading the Zen of Programming by Jeffrey James. Published in 1988. There are three parts to go. The book is a tongue in cheek nod to the works of the real Zen tradition. The author has repurposed them into a text on programming. The result is unlike any book on programming I've ever read. It's poignant, accurate and funny. It's truly a rare treat. The text is divided into five books. Each book is attributed to a different master in the Zen programming tradition. Book two is attributed to Master Noah Ope. It features folktales from his collection. In this episode, I'll read each of the folktales and comment when necessary. Before we get into it, I need your support to keep small batches going. There are two ways you can do that. You can support me directly on Patreon or by subscribing to Software Kaizen on substack. Your support allows me to keep making fun in educational software delivery. Education like this episode. Find links to Both at Smallbadges FM 118. Thank you very much. Okay, now time for the Zen of Programming. Master Noah up was a collector of folktales about various development projects. Recent computer archaeological research has revealed that the folktales in this volume are based upon historical fact. Although a certain amount of exaggeration may have been inadvertently added, the core historical truth remains. Folk tale 1. When Prince Xun staffed his software projects, he would hire 300 developers on a single day. A scholar who had a PhD in computer science asked for a place in the company and was granted a well paying position. One day, the princess was deposed by the warlord Min. I believe in individual accountability, declared Warlord Min as he reviewed his troops. Hearing this, the scholar quietly slipped away. This folktale makes me think of the red beads. Management by Objective and Systems Thinking. Let's assume for a second that the scholar has profound knowledge. He understands that he will now be held accountable for how many red beads he moves. Better for him to leave now than deal with participating in this system. And if you don't know about the red beads, I'll put a link to all the Deming stuff in the show. Notes. Okay. Folktale 2. Two programmers were arguing about user interface. Significant inroads are being made in ease of use, said the first programmer. Soon people will no longer need to read tedious manuals before they can use a computer. Programs will be self evident. The second programmer thought about this for a moment and then said, hmm. Last weekend I decided to chop some wood for a fire, but my old axe was dull and worn. So I went to the hardware store and purchased a new one. That's all very interesting, said the first programmer. But what does it have to do with user interface? The new axe came with an eight page instruction booklet, he replied. I have a lot of thoughts on this folktale. Actually, uh, this folktale reminds me of a recurring conversation I've had around the ever increasing complexity of cars. Sure, drivers have always needed some guidance in the early days. Here's how you'd start the car with a crank and this is how gears work, etc. Etc. Though that's about where the user interface ended. There were ways to start and stop the car, accelerate and decelerate. These days cars do so much more. Uh, myself having owned cars from the 60s, there was much less complexity. Now I may need to consult the owner's manual to operate some new exotic feature. And yeah, it's also in the surprising sub menu on the touch screen. Where else would it be? Though? I think the point of this folktale is about adding unnecessary complexity. An axe does not need an, uh, instruction manual. So what has possibly been done to require it? The trend to newer with added complexity is not always a good thing. I think all programmers can learn something from this folktale. I recommend that you meditate on this before adding something new. Especially if you're starting a brand new project or considering building something from scratch. Think about how you can make it simpler. Alright. Folktale 3 A sage once asked an engineer, a mathematician, a physicist and a programmer, how many sides are there to a box? The engineer replied. First there are four sides to a box, he said. Why do you say this? Asked the sage. The four uprights are on the sides, which are joined together by a top and a bottom, replied the engineer. This is ridiculous, remarked the mathematician. A box has six sides. Why do you say this? Asked the sage. A box is a cubiform, therefore it has six sides, added the mathematician. That is untrue, said the physicist. A box has 12 sides. Why do you say this? Asked the sage. Strictly speaking, there are six sides on the exterior and six sides on the interior, replied the physicist. The sage looked at the programmer, who as yet had said nothing. What is your opinion? Inquired the sage. There are only two sides to a box. Said the programmer. At this the engineer, mathematician and physicist began to laugh. Why do you say that there are only two sides? Asked the sage when the laughter ceased. This is based upon personal experience of the programmer. The inside is where the circuit boards are mounted. The outside is where you put the monitor and keyboard. Exactly so, said the sage. This folktale gave me a chuckle when I read it the first time. I can't help but feel that the programmer considered an architecture diagram when answering the question. In that case, there are only black boxes inside, complexity with functionality, and outside to plug stuff in. I think also this folktale makes you consider the matter of perspective and the implicit context we all operate in. Okay. Folktale 4 a newly appointed director was holding a get acquainted meeting, um, for the programmers. In the midst of the revelry, a programmer recited the following. We have looked forward to your arrival with anticipation. Your predecessor had none of your exalted ability. Now that you are here, we can become truly productive. The new director was highly flattered. Did you write that speech yourself? He asked. It is custom of the development center, said the programmer, to give that speech whenever a new director arrives. It is the only speech I know, so I will admit that I have read this book now a few times before reading it on the podcast and sometimes it's hard for me to contain my laughter when I read these. I think that some of these are just, you know, too true and get to some core truths about the work and the industry that we are all in. But it's not immediately obvious. Can tell that this guy has been through a few rounds of directors and now it's just going through the motions. Folktale 5 One day a programmer at the development center discovered an algorithm that would create mazes. Being industrious, he modified the algorithm so that it would create a single maze on long strips of printer paper. Soon he had generated a maze containing several million paths, 40ft long and 7ft high. He hung the maze in a long hallway across from the programmers offices. Soon the entire programming staff was crowded in front of the maze trying to solve the Titanic puzzle. The director of the development center happened by and stared at the scene in sad dismay. But when he went to the master programmer's office to ask advice, the master was not there. The master was obviously working on the puzzle. Can't keep programmers away from a puzzle. Folktale 65 novices went into the Master's office crying. Whoa, whoa. Uh, we have heard that our project may be canceled, the master said. All things continue until they stop hearing this. The novices return to work. You know, just because a project may end does not mean to abandon it early. You must manage your attachments. And this is where we get into the overlapping connection to actual Buddhism Systems and the projects inside them. Do not care about your attachments to the programs. We'll have more on this, uh, later in the book. Folktale 7 One day, the development center received news that a new director was to be appointed over them, a warlord who knew little about computers. Appalled by the news, the programmer stopped coding, but instead spent many hours speculating about the evil days to come. Seeing this, a UH master decided that something had to be done, so he rented a guerrilla suit. Presently, the new director reported for duty. He gathered together all the managers in the small conference room, along with several corporate executives sent from the headquarters to smooth the transition, as the saying was. Suddenly the master, dressed in the gorilla suit, burst through the door. He leapt upon the conference table and kicked the papers around and growled at the executives who just sat there with their mouths agape. Then he left as suddenly as he came. Upon hearing of this event, the programmers returned to work, and here is a special note from the editor. The editor has spoken with several people who witnessed the events described in this folktale. Folktale 7 the editor has also heard that a similar act of defiance took place at the IBM facility about a year later. The second incident was somewhat different than the first, in that the programmer wore a sports jacket, stood in the doorway, and coughed loudly. Folktale 8 a group of programmers were presenting a report to the emperor. What was the greatest achievement of the year? The emperor asked. The programmers spoke among themselves and then replied, we've fixed 50% more bugs this year than we fixed last year. The emperor looked on them in confusion. It was clear that he did not know what a bug was. After conferring in low undertones with his chief minister, he turned to the programmers, his face red with anger. You are guilty of poor quality control. Next year there will be no bugs, he demanded. And sure enough, when the programmers presented the report to the emperor, next year there were no bugs. So ask and ye shall receive. The omission of the comments on bugs does not mean that they are absent. Though people may want to believe that this is not the point of the folktale. The emperor does not understand that bugs will never go away. This is evident by his request. The programmers know this. They also know there is no way to satisfy the request. So better to omit them than to disturb the Emperor. Meditate on, uh, where you can observe this in your own daily work. Folktale 9 a corporate executive came to visit the development center. Like a general reviewing his troops, he walked the long corridors, stopping here and there to talk with the people that he met. Eventually he wandered into the office of a programmer who, as it happened, was in deep concentration debugging the operating system. The executive glanced upon the room and noticed a statue of a pig that was perched upon the programmer's terminal. I have always been fascinated by the curios and mementos the programmers collect, said the executive. They always seem to have some interesting tale behind them. For example, what is the meaning of that sculpture there? He pointed at the statue. The programmer looked up from his terminal, blinked, and then stared at the statue as if he were seeing it for the first time. It's a pig, he said. And that's all. For this batch, you can get your own guide to the Zen of Software Delivery. I call it the Small Batches Way. The PATH has four Understanding of Continuous Delivery, Understanding of Software Architecture Understanding of Production Operations Operations and Understanding tdd. The PATH contains everything you need to become one of the new Zen Masters. Get the guide at thesmallbatchesway.com Anyway, I hope to have you back again for the next episode. So until then, happy shipping.