13. Literal Time-Space Tradeoffs

Jocelyn Goldfein on Software Engineering Daily, Michael Bolton on Engineering Culture by InfoQ, Dave Snowden on Engineering Culture by InfoQ, Ben Orenstein on Software Developer’s Journey, and Claire Lew on Greater Than Code. I’d love for you to email me with any comments about the show or any suggestions for podcasts I might want to feature. Email [email protected]. This episode covers the five podcast episodes I found most interesting and wanted to share links to during the two week period starting June 10, 2019. These podcast episodes may have been released much earlier, but this was the fortnight when I started sharing links to them to my social network followers. JOCELYN GOLDFEIN ON SOFTWARE ENGINEERING DAILY The Software Engineering Daily podcast featured Jocelyn Goldfein with host Jeff Meyerson. Jocelyn talked about joining Facebook after having spent years at VMWare delivering shrink-wrap software that had a release cycle on the order of years. Witnessing the cadence at which Facebook delivered new releases firsthand, it appeared to her like Facebook was defying the laws of physics. The cost of a release had shrunk to nearly zero. She says that companies that start life developing for native, that is, developing shrink-wrap software like that of VMWare, never really shake off the culture of developing for native. These cultures define a good engineer as someone who can estimate precisely and deliver predictably and it is all because the cost of a release in that native software world is so high. She talked about the often unacknowledged tradeoff between productivity and predictability. She also talked about the flexibility the engineers obtained by shipping more frequently. Not having to hit infrequent, high-risk release windows meant that engineers could stay “on the balls of their feet” and, say, have the news feed team help the photos team because they were not going to miss some “huge release date in the sky” by shuffling tasks and reprioritizing. By the way, I love Jocelyn’s colorful metaphors. She said that being able to move people around fungibly to unblock each other ends up being a “turbo button for the entire organization.” She says that the combination of removing deadline pressure and continuously integrating new features behind feature flags into the single branch that all of Facebook ran on allowed the engineers to be agile and to “reserve the right to wake up smarter and make a better decision tomorrow” based on actual usage. This is in contrast to many software teams that spend so much time making a perfect product before they finally get feedback that they become both psychologically committed to their design and physically committed to it (through a hard-to-change code base). At Facebook, the “concrete was still wet” until incredibly “late in the game.” The architecture and the release process at Facebook let them “jettison some sacred cows,” specifically, the notion of deadlines and the idea that you only get feedback at the end. She says that Mark Zuckerberg has many gifts but one of his superpowers is to be able to admit when he was wrong. She says she doesn’t think people can reliably distinguish good innovative ideas from bad ideas without trying them out first and she believes Facebook has been innovative because their architecture, release process, and values system allowed them to take risks. She says, “Facebook’s genius is not that it is right any more than anybody else. It is that it tries experiments at a higher velocity than anybody else and it purges the ones that don’t work faster than anybody else. It is no surprise that, in the end, the deep-seated challenges for the company have been problems that don’t show up immediately — problems where the downsides were incredibly lagging indicators.” Apple Podcasts link: https://podcasts.apple.com/us/podcast/facebook-management-with-jocelyn-goldfein/id1019576853?i=1000438147913 Website link: https://softwareengineeringdaily.com/2019/05/15/facebook-management-with-jocelyn-goldfein/ MICHAEL BOLTON ON ENGINEERING CULTURE BY INFOQ The Engineering Culture by InfoQ podcast featured Michael Bolton with host Shane Hastie. Shane started by asking Michael whether testing is blasé today. Michael said that you can choose to look at it that way but nothing is more fascinating to him than testing, which he defines as evaluating products by learning about them through exploration and experimentation. He also says that testing is focused on a question that nobody else is interested in asking or answering, which is: Are there problems that threaten the on-time successful completion of the project or that threaten the value of the product? Michael sees his job as helping people get comfortable with the process of looking for problems that threaten value so that managers can find out whether the product they have is the product they wanted. In response to a question from Shane, Michael brought up a conversation in which someone said that you often look at a piece of software and think to yourself that it couldn’t have an effect on human life or health or safety. But you don’t know how people are going to use your product. A developer of Microsoft Excel might think, “Nobody’s going to die if there is a bug in Excel.” Somebody could easily lose a mortgage due to a bug in Excel and when a product is used as ubiquitously as Excel, you are not going to see the knock-on effects of the risk. He talked about the problem of needing to maintain a critical distance to spot the problems that arise from complexity. He said that unit tests may demonstrate that the individual units of a program can all be individually reliable, but they would not demonstrate that the overall product is safe. He gave an example from Nancy Leveson’s Engineering a Safer World of a chemical reactor in which the software that controlled the flow of water and catalysts into the reactor was designed to leave all control variables as-is and sound an alarm in response to a fault. This sounds reasonable, but a situation occurred in which a fault was triggered just after the catalyst was added to the reactor. The cooling water flow had not yet ramped up and fault policy meant that it stayed at this low level as the system got hotter and hotter. The reactor overheated, the release valve lifted, and the contents of the reactor were discharged into the atmosphere. This illustrated how putting simple things together into a complex thing creates complex problems we are not great at anticipating. The solution he says is to experiment with the system in the same way Hook, Boyle and their contemporaries in the 1600s were doing: putting the system into conditions that are not normal so as to reveal surprises. It is the tester’s job, Michael says, to be professional skeptics. The problem, he says, is that the critical distance of a good tester is bound together with social distance. Nobody wants to receive bad news and testers are often the people delivering the bad news, creating social distance from the rest of the team. The social challenge for testers is to help people appreciate getting the bad news. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/michael-bolton-on-the-testing-mindset/id1161431874?i=1000438906048 Website link: https://soundcloud.com/infoq-engineering-culture/interview-michael-bolton DAVE SNOWDEN ON ENGINEERING CULTURE BY INFOQ The Engineering Culture by InfoQ podcast featured Dave Snowden with host Shane Hastie. After asking Dave to introduce himself, Shane asked about the liminal aspects of the Cynefin “model” and Dave made the correction that Cynefin is actually a framework rather than a model because it doesn’t seek to represent the world but to give a perspective on the world. Dave explained that regarding liminality, Cynefin started with five domains and a set of dynamics for moving between domains but this confused people, so they introduced liminal zones to represent this state of transition. He pointed out that the Scrum framework holds things in the liminal state between complicated and complex long enough to get them right and this is a strength of Scrum. They talked about the need to run parallel safe-to-fail experiments when in the complex domain and Dave gave three examples. The first was to break people up into trios and spin off 30 or 40 trios to look at a problem in their spare time over a week. The second example was to create a prototyping team and put them with users for a day to build a prototype and then pass the prototype on to another team charged with improving it without the original user input. The third example was to do continuous mapping of unarticulated needs and, when they get statistically significant clusters, put small prototyping teams on each cluster. Dave told a story about creating a fake infographic about a cybersecurity breach in one industry, giving it to employees in a different industry, and asking them to tell a story about why it couldn’t happen to their company and a story about what they would do if it did. He then analyzed these stories to look for complacency. More generally, he would use this technique and look for outliers because, when you want to create significant change, you need to look to the outlier groups rather than the dominant groups. Shane pointed out the contrast between this technique and common requirements-gathering techniques and Dave responded that requirements-gathering allows bias to creep in after the first few interviews. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/dave-snowden-on-liminality-in-cynefin-moving-beyond/id1161431874?i=1000438021618 Website link: https://soundcloud.com/infoq-engineering-culture/dave-snowden-on-liminality-in-cynefin-and-moving-beyond-agile-to-agility BEN ORENSTEIN ON SOFTWARE DEVELOPER’S JOURNEY The Software Developer’s Journey podcast featured Ben Orenstein with host Timothée Bourguignon. They talked about Ben’s academic challenges, his initial lack of maturity, his discovery of Ruby and then Rails, and his growth as a software developer under the tutelage of his former boss and mentor. Tim asked Ben what he would be looking for in a junior developer to have as a mentee and Ben answered that he would look for something like grit (the ability to push forward and not get too discouraged) because the kinds of problems we face as software developers require grit to get through and this never really goes away as you become more senior and experienced. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/51-ben-orenstein-advises-us-not-to-worry-too-much/id1079113167?i=1000439883363 Website link: https://www.buzzsprout.com/190346/1195571 CLAIRE LEW ON GREATER THAN CODE The Greater Than Code podcast featured Claire Lew with hosts Janelle Klein and Sam Livingston-Gray. The panelists asked Claire the standard “What is your superpower?” question and, after answering, she turned the question around to them. They then entered the topic of bad bosses in which Claire told her own story and then got Janelle and Sam to tell their own bad boss stories. Sam told the story of his experience with a command-and-control CEO and this led to a discussion about when motivating through fear is and isn’t effective. Sam related this to a book by Courtenay Hameister called Okay Fine Whatever that describes the negative effects of stress on one’s ability to be creative. This reminded me of the section of the book Switch by the Heath brothers about the burning platform concept and how negative emotions stifle creativity. Claire pointed out another problem with command-and-control leadership is that it disregards the belief that people are ever intrinsically motivated. She says that while there has been a shift to leaders being told they need to inspire people rather than command and control them, there is still an implicit reference to control. People say things like you need to “empower” people. She hates that word. She says people are already empowered. Leaders need to create an environment that lets their people do their best work and then just get out of their way. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/132-distilling-the-hailstorm-with-claire-lew/id1163023878?i=1000440034174 Website link: https://www.greaterthancode.com/distilling-the-hailstorm FEEDBACK Ask questions, make comments, and let your voice be heard by emailing [email protected]. Twitter: https://twitter.com/thekguy LinkedIn: https://www.linkedin.com/in/keithmmcdonald/ Facebook: https://www.facebook.com/thekguypage Instagram: https://www.instagram.com/the_k_guy/ YouTube: https://www.youtube.com/c/thekguy Website: https://www.thekguy.com/ Intro/outro music: "waste time" by Vincent Augustus