26. Patience and Brainpower

Emily Bache on Maintainable, Rod Collins on With Great People, Dominica DeGrandis on Troubleshooting Agile, Ariel Caplan on Greater Than Code, and Dave Aronson on Maintainable. 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]. And, if you haven’t done it already, don’t forget to hit the subscribe button, and if you like the show, please tell a friend or co-worker who might be interested. This episode covers the five podcast episodes I found most interesting and wanted to share links to during the two week period starting December 9, 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. EMILY BACHE ON MAINTAINABLE The Maintainable podcast featured Emily Bache with host Robby Russell. Robby started out by asking Emily about common traits of maintainable software. She says that maintainable software has a design, is well tested, has names that relate to the domain, has had thought given to having levels of abstraction, and is the kind of code you would like to read. Robby asked Emily what developers get wrong when talking about technical debt. She says that some developers label as technical debt any code they don’t like or didn’t write themselves. Other developers don’t even admit that there is any such thing. This is problematic because there really is code that is bad, code that most developers would have trouble understanding. She says that your decisions regarding technical debt have to be driven by the needs of the users of the software. Code you don’t need to change doesn’t need to be improved.  They talked about examples of bad code and Emily mentioned Terry Hughes’ Gilded Rose refactoring kata as an example of horrible code that she uses to educate others. She herself invented a tennis refactoring kata and a Yahtzee refactoring kata that I got to try out myself in her workshop at the Agile Testing Days conference in November.  Robby asked whether these exercises are meant to be done alone or with others. Emily says it is always more fun to code with other people and you learn more. She says coding is a social activity. Very little code today is written by individuals. It is written by teams. Doing exercises like the tennis kata in a group lets you have discussions about design and code smells without it being personal and then you will have practiced such discussions for when it really matters in your production code. Robby and Emily talked about the individual genius developer and Emily says that while there are definitely still instances of software built by geniuses working alone, the best software today is often built by teams from the start. This led her to talk about mob programming, which she favors because it forces you to explain your ideas in words. You have to become good at communicating, in words, about software design and coding constructs. She says she didn’t have that skill when she started mob programming. Robby stated that he wasn’t familiar with mob programming. Emily explained that, as in pair programming, you have two people working together at the same machine, but in mob programming you have more than two people and, because of the increased number of people, you need an increase in structure. One piece of structure is that the driver, who is typing at the keyboard, cannot follow their own ideas about what to write. Instead, the navigator, a designated person in the mob, communicates what code should be written. The rest of the mob supports the navigator and the driver and you regularly rotate the roles. For the mob to work, the navigator has to get good at communicating in words, not just with the driver, but also with the rest of the mob so that they can assist and can take over when the navigator rotates to the driver role and the driver returns to the mob. They discussed how often to rotate and Emily says it varies from team to team, but her preference is to rotate every four or five minutes. As an aside, at the Agile Testing Days conference this past November, I got to experience a mob programming workshop led by Emily in which I got to be a member of the mob and rotate through the roles of navigator and driver and I highly recommend seeking out opportunities to experience this style of work if you get the chance. They talked about her work as a technical agile coach and how she splits her time among multiple teams at a given engagement, working with each team for two hours every day. These teams would work as a mob on their production code and she would sit in the mob and either take the navigator role, coach the navigator and driver, or simply observe. This allows her to help teams to learn practices like writing tests, doing refactoring, improving their design, breaking their work into small pieces, committing often, writing good messages, and all the stuff you need to do to be agile. They also do one hour coding dojos.  Being a guest in other teams’ codebases, she says, you have to be respectful because even when you see that the code is bad, you don’t know why it got that way. The first thing she does when she joins a new team is ask to see their code, their unit tests, and the code they find most difficult to work with. Robby asked Emily to reflect on the various projects she has participated in and describe common issues that affect most teams’ code and processes. Emily says she sees a lot teams struggling to meet expectations and not taking enough time to really communicate with each other and improve. Most software developers really want to do a good job and are under a lot of deadline pressure that works against doing a good job. Software development is a marathon and you have to make sure you are learning and your processes are improving as you go. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/emily-bache-its-always-more-fun-to-code-with-others/id1459893010?i=1000457798211 Website link: https://maintainable.fm/episodes/emily-bache-its-always-more-fun-to-code-with-others-PtzH4tY7 ROD COLLINS ON WITH GREAT PEOPLE The With Great People podcast featured Rod Collins with host Richard Kasperowski. Rod says that, in the 20th century, if you wanted to scope out the future, you looked backwards. You understood your business, product, and market metrics and forecasted from that because, in those days, the past was a proxy for the future. Today, the world is rapidly changing and planning can become a strategic trap. Planning is no longer the foundation of strategy. The basis of strategy today is discovery. Richard asked why Rod calls himself an information curator and Rod said that no one person can see into the future, but if you have processes that leverage the collective intelligence across experts, non-experts, and what Rod calls unusual suspects, it gets businesses to ask the right questions and find the unknown unknowns. Rod says that most leadership teams, especially senior leadership teams, don’t spend sufficient time on business strategy. When your challenge in a business environment is discovering the unknown unknowns, you cannot afford to meet only once a year to think about business strategy. Rod had his own leadership teams meet about strategy for a whole day every two weeks. Rod asks, “How much of a CEO’s time is spent bridging gaps between the various units because they are not getting along?” Meeting for a day every two weeks pays itself back many times because senior leaders are able to handle issues among themselves without involving the CEO. There is esprit de corps, a history that gets created among the leadership team, and the collaborative way of working together becomes the natural way of conducting business. Rod says that the leadership training of the last five decades is focused on the individual. Most train strategic leaders to hold their hierarchical authoritative power in such a way that it is beneficial, but treat leadership as fundamentally residing within the individual. Rod thinks that part of the transformation of 21st century business is the unit of leadership changing from the individual to the team. Leadership training, as a consequence, needs to happen in the context of full teams. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/rod-collins-innovation-discovery-how-to-do-it-right/id1262784541?i=1000457926652 Website link: https://soundcloud.com/withgreatpeople/episode28 DOMINICA DEGRANDIS ON TROUBLESHOOTING AGILE The Troubleshooting Agile podcast featured Dominica DeGrandis with hosts Douglas Squirrel and Jeffrey Fredrick. Squirrel and Jeffrey asked Dominica what she means by time theft. She says that time theft is the interruptions and context switching that often comes from conflicting priorities, unknown dependencies, and unplanned work. For example, you may go to work and have back-to-back meetings and cannot get your real work done until you put the kids to bed or on Sunday afternoon. As Squirrel says, “You can’t do your work at work.” It prevents you from getting into the flow state described by Csikszentmihalyi. If you ask people what prevents them from getting their work done, they often say it is because they are overloaded. She told the story of working with a team of 41 engineers working on 33 projects at the same time, building out six data centers in six countries in six months. They were carrying the duty pager and were interrupted so much that they put two project managers in front of them to protect them from the inbound demand, but their mutual dependencies within the organization interrupted them too. The project managers put a big Kanban board up and, every time an engineer was interrupted, they put a post-it on the board. In a week, they had 92 interruptions and the majority were due to product managers wanting to know the status of their project. Every day, people were walking past this board and this is how you get visibility on your problem. Making the work visible provoked the necessary conversations to inspire change. The change that occurred was taking one of each specialist, moving them into a different building and asking them their biggest pain points. Because work was being started without finishing previous work, they had a lot of projects at 90%. This isolated team was able to finish 10% of the projects in four weeks. As a build engineer, Dominica used to rant about teams not having enough automated testing but it got her nowhere, but once she started capturing the data, taking a scientific and systems-thinking approach, and presenting her data-backed case to leadership, the result blew her away. She got budget, she got headcount, and she got empathy. Jeffrey said that people often find themselves on an us/them divide and this is not what Dominica found once she could present the data to leadership. The problem is that people don’t have the shared information to work from and, in making the work visible, she was generating information that nobody had before. Squirrel says he worries that people will use the metrics to beat people up. Dominica says this is why we want to focus on business outcomes and not activity metrics. A lot of proxy metrics are captured because it comes with the tool, but these metrics don’t tell you how much business value a team is providing for the company. Dominica likes to use a balanced set of flow metrics such as cycle time and flow efficiency. Squirrel asked why the business leaders would be interested in such metrics. Dominica gave the example of business leadership thinking they need to hire more developers because the teams they have are not delivering fast enough. If you are measuring flow efficiency, development time is usually a low percentage of flow time, so adding more developers would not help cycle time at all. You need to know where your bottleneck is and measuring flow efficiency helps you make these kinds of business decisions. Jeffrey asked where someone should start in making work visible and reducing time theft. Dominica starts with the question of what prevents a team from getting work done. Decide on a few small experiments of four to six weeks to address these problems, find that one person on the business side who can be your ally and maybe sponsor these experiments, and address their business pain. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/making-work-visible-with-dominica-degrandis/id1327456890?i=1000458010204 Website link: https://soundcloud.com/troubleshootingagile/making-work-visible-with-dominica-degrandis ARIEL CAPLAN ON GREATER THAN CODE The Greater Than Code podcast featured Ariel Caplan with hosts Jamey Hampton, John K Sawers, and Jacob Stoebel. Ariel says his superpower is extreme irritability. He had to learn when to address the things that irritated him and when to let them go. He started a daily writing practice of noting what irritated him that day and also what he liked. He connected his superpower to accessibility. He says you can develop in yourself a sensitivity to examples of poor accessibility like the use of red and green as the only means to present certain information in a user interface. Ariel has been working on developing the corporate values for the company he works for. Ariel says that company values are often viewed with skepticism and he gave an example: a company had the values of communication, respect, integrity, and excellence, according to their annual report in 2000. The name of the company was Enron. John talked about helping his team of about 25 people come up with their team values to use as an interviewing rubric. He liked asking about values in interview questions because there is no wrong answer and, by asking the candidate what a good demonstration of a particular value is, it allows you to evaluate how they think that the value would play out instead of having them guess the magic answer to a tricky interview question. Jamey added that it is important to revisit your list of core values every so often. His company, Artemis, grew from ten to thirty employees and decided to revisit their values. Some of the values did not change fundamentally, but changed meaningfully in the way they were expressed. Ariel asked about when is it time to delete a value from your list and Jamey described how the original list of Artemis’ “values” included company goals like “we help indoor growers succeed”. These got removed because they weren’t really values, but they remain corporate goals.  Ariel says he pays attention to who is impacted and has to change their behavior because of a value. He gave as an example the values of grit, determination, and hard work and how this gets abused to put pressure on the front-line workers. Another example is a value like: “we challenge people; we ask questions; etc.” A better value might be “we create an environment where it is safe to ask questions, safe to challenge ideas, and safe to take risks.” The first example puts the pressure on the front-line workers to behave a certain way, while the second puts the pressure on management to create a better environment. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/158-exploring-company-values-with-ariel-caplan/id1163023878?i=1000458078372 Website link: https://www.greaterthancode.com/exploring-company-values DAVE ARONSON ON MAINTAINABLE The Maintainable podcast featured Dave Aronson with host Robby Russell. Robby asked Dave what his definition of software quality is. Dave addresses quality for the vast majority of software as a list of six aspects that form the acronym ACRUMEN: appropriate, correct, robust, usable, maintainable, and efficient. The N means nothing. Appropriate means doing what the stakeholders need it to do, where the term stakeholder refers to users, customers, operations personnel, and others. Where Appropriate refers to doing the right job, Correct means doing the job right. He uses the analogy of being asked to write a checkers program and, in response, writing the world’s greatest chess program. It can be as correct, robust, usable, maintainable, and efficient as anyone could ever possibly want, but if you wanted a checkers program, you are not going to be happy with it. In ACRUMEN terms, the chess program is not appropriate. Alternatively, a perfectly reasonable checkers program that may even have a few bugs is probably going to suite your needs better than a fantastic chess program. For Robust, he is mostly referring to security. He uses the CIA triad (confidentiality, integrity, and availability). The program should not reveal information, alter information, or become unavailable when it is not supposed to. Regarding Usable, Dave says it is not just the end user that needs to find the software usable; things like an API should be usable as well. In ACRUMEN, Maintainable means easy to change with low fear of error and low chance of error even for a novice programmer new to the project. Fortunately, the vast majority of software engineering advice is aimed squarely at this. For the last letter in the acronym, E for Efficient, Dave says there are more resources to make efficient use of than CPU cycles. There is, of course, disk space and network bandwidth, but also the user’s patience and brainpower, and the company’s money. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/dave-aronson-putting-the-m-in-acrumen/id1459893010?i=1000455264616 Website link: https://maintainable.fm/episodes/dave-aronson-putting-the-m-in-acrumen-n_6lX9fc LINKS 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