This is a transcript of episode 225 of the Troubleshooting Agile podcast with Jeffrey Fredrick and Douglas Squirrel.

Squirrel and Jeffrey ponder the seemingly forgotten lore of their younger days and ask how those lessons will make it to the next generation..or does such a fast moving industry have no time to learn from the past?

Show links:

Listen to the episode on SoundCloud or Apple Podcasts.

Introduction

Listen to this section at 00:11

Squirrel: Welcome back to Troubleshooting Agile. Hi there, Jeffrey.

Jeffrey: Hi Squirrel.

Squirrel: So we were working together, broadcasting on the Internet, but I didn’t start with “Welcome back to Troubleshooting Agile.” We were together on a live stream, part of my Squirrel Squadron series, and we were discussing releasing 50 times a day. That was a lot of fun, but it wasn’t a podcast.

Jeffrey: Yeah, it had a lot of the same elements: us discussing things, but it was kind of fun because there was a history lesson element, which we do less of here on the podcast typically.

Squirrel: Yeah. You thought it would make also a good podcast episode because of some things that happened afterwards. Do you want to tell our listeners about that?

Jeffrey: Yeah, I was inspired to bring it up because there had been someone on Twitter who retweeted it—thank you for that—and they mentioned that what stood out to them was where we were talking about how to make small changes. This was an interactive discussion and someone had made a comment about how difficult it is when there’s a database involved and changes are breaking. I described a pattern of how you can make incremental changes such that you evolve your database, so that it always works and you don’t have a single breaking change. I won’t bother repeating it here because you can listen to it in the recording of the livestream, which we’ll put in the show notes. But in response to the tweet I wrote back “if you like this, you’ll probably like this book called Refactoring Databases.” I gave them a link and they were they were pleased about that, but it had me wondering. There is so much knowledge that has come out, and it’s one thing to learn the things that are current, but what happens to knowledge from long ago, decades ago? “50 times a day” was inspired by a blog post from 2009, we’re talking about something that’s literally more than a decade old. The book is even older.

Squirrel: The thing that drove me nuts about both of them was the fact that the these ideas had been learned, and then forgotten. Now people are asking me, “how do we use this thing called continuous integration? We all seem to have it. How should we use it?” How could you not know about releasing 50 times a day? How could you not know about refactoring databases in this incremental way if you’re using continuous integration? In some sense, we retained only half of the idea.

Learning in Circles

Listen to this section at 02:56

Jeffrey: That’s right. It made me think, this has got to be true for our other classics as well. One of the most cited books at CITCon in the 2000s would have been Michael Feather’s book Working Effectively with Legacy Code, one of the classics for anyone doing testing and trying to bring testing into an existing code base, which would be most people! That was such a seminal book, and I wonder how many people are even aware of it today? It might be a lost gem. So I wonder, what do you do if you have a new development team and you’re wanting to get better? How do you know about these? I remember the solution that that you had at TIM Group that kind of explained how I ended up working there, which is someone said, “Oh, you need a gray beard. You need to have someone who actually knows about these things and experienced them in real time.” But I find that very odd that we would be so dependent on the individuals who happen to live through the experience when these things are being formed. It’s left me with this puzzle: are there other ways that we can expect people to be able to get in touch with the literature that’s out there? Is that just not a concern that people have?

Squirrel: It strikes me that in some sense I make my living by being such a gray beard, although my body steadfastly refuses to grow any kind of beard, much less a gray one. But we hired you, Jeffrey, because we wanted a storyteller. What do you call them? A shaman or a historian, sitting around the campfire telling us what sorts of things people had tried before, and you would reach back—I remember our CEO remarked on this, he said “It’s just amazing how many stories Jeffrey has from 1992. He keeps telling us about Borland, and I don’t even remember what Borland was!”—but you drew on those stories and they pointed us to the right material, and then we could learn the material, and it was very helpful to us. I kind of function that way for my clients, I think you do, too. A lot of people have asked me in the last day or so about handling a conversation in which someone yelled at them, and I’ll refer them to material I was reading and studying with you back in 2010 from Chris Argyris, or they’ll inquire about how they can help someone to get onboarded very quickly and I’ll say, “have you tried this thing called pairing?” If they’ve never heard of it, then I know that there’s rich material there in bringing that back up to them and I can refer them to the XP Explained and other materials. Of course we have wonderful tools for pairing now, but that’s yet another practice that has has kind of made its way through the hype cycle. It’s settled down to a relatively low level of hype, and you need a gray beard to find it for you, it seems to me. I’d love to hear about another way.

Jeffrey: Yeah. I’m really curious if people see it as a problem; maybe they’re like, “Well no, I just go to StackOverflow. Google solves this for me. I don’t need to find books. I don’t need to know who wrote the book. I just need the answer.” I wonder if that’s how people see it. I remember one of the things that struck me very early in my career—again back in the olden days while I was at Borland, maybe 97 or so—I was reading a book that was making the point about how few developers at the time read books. That was maybe more remarkable at the time, because now there’s a lot of other options, you know, people can be watching YouTube videos, there’s a lot of interactive tutorials on the net, you can go search and find lots of resources. That was much less true in 1996, 97. This author was referencing even earlier and remarking how few people ever read an article on programming, how few people ever read books on programming, how few people attended conferences. In other words, how little effort as a profession people put into learning about their profession. That was a striking insight to me because I was naturally always interested in reading. I always had the view as you said that someone else must have solved this. My whole view of science was that we grew by having common literature. I don’t know that this happens in software, maybe it never happened in software. How do people learn about the literature and what the classics are? There’s probably a handful of classics that people still read. I imagine Mythical Man-Month might be one of the oldest books that might still get referred to new programmers.

Squirrel: It was on my father’s shelf.

Jeffrey: Was it really?

Squirrel: It was, yeah! I used to read it when I was ten and I didn’t understand any of it. I just thought, my dad has it, it must be a good book. “What on earth could these weird words mean?” I didn’t really understand it till I reread it 20 years later.

Jeffrey: It’s reasonable that maybe that we don’t have a literature that spans centuries, given that it is a relatively new profession. But the canon of programming literature, things like Peopleware or Code Complete or The Pragmatic Programmer, will these things be remembered and put out there as something worth reading 20 years or more after they were published? And where does someone go to learn about the foundational books? I guess the answer is you go ask on Twitter, but I wonder if you get recency bias there.

“The lone and level sands stretch far away.”

Listen to this section at 09:44

Squirrel: I have the feeling that one reason people don’t do that kind of thing, a reason they may not go and look, is that in software, it always feels like you’re doing something new. “Nobody has ever built an automated drone delivery system for Rubik’s Cubes. We’re building the first one. It’s very difficult to pick up the cube, the mechanics of actually getting the gripper to grip a smooth cubical surface, that’s really tough. So why would we need to consult the history books in order for somebody to understand how to do this?” In fact, the problems of testing that system and refactoring that system and deciding whether this is actually a good idea are all problems that people have been struggling with throughout the history of software, but it somehow feels new. I wonder if that’s a driver.

Jeffrey: That’s a good point. It’s certainly at least because all the technology is changing, the languages are changing, the frameworks are changing, so much of what you’re looking at on screen changes, it might feel like there’s no relevance to those earlier times in earlier lessons. I recall being at conferences back in the 2000s and listening to Robert C. Martin or Uncle Bob, as people would call him, someone who’s less referenced these days. One of things that was notable about his talks is he would often ground his talks in classic literature, he would cite books from the seventies in the 2000s. He would say, it’s worth understanding the lessons that past generations learned because it helps us understand what’s constant about programming, what’s constant about making software, and that we can get better insights into these things, with the passage of time, and to take the heart of the lessons with us.

Squirrel: I remember something Steve Jobs said. He said in 1000 years, people will just remember that something happened back in this ancient time, they won’t remember whether it was the 20th or the 21st century. Kids will get it mixed up in school, but there’ll be a kind of accretion of archaeological layers. At that point, we will have solved a number of difficult software engineering problems, assuming the human race continues. But he said it’s very unlikely that people will remember any of our individual contributions. Most of us will not be memorable for our individual contribution the way we remember Galileo or Einstein hundreds and hundreds of years later. But what we can hope to be part of is that accretion of value. The thing I slightly worry about is that there may not be as much accretion because some of it isn’t seeping through. Maybe it just is a process of re-remembering.

Jeffrey: That’s a good point. And actually, it touches on in the Agile Conversations Slack group, there was a listener who we both used to work with, Joel, who was taking us a bit to task for our analogy last time of cooks versus nutritionists.

Squirrel: Ooh. Okay. Criticism, excellent, and from a great source.

Jeffrey: That’s right. Joel made the point that these metaphors and analogies can confuse and hide differences as much as they illuminate. He made the case that by contrast the jargon—although he calls it domain-specific language—can be very powerful and helpful. It had me thinking: jargon is fantastic, but you need enough common experience, you need to build up a shared understanding of what the jargon means, and that one of the challenges it occurs to me with having a discipline where people aren’t collecting the lessons and over time, they aren’t accreting, is that maybe that comes out a bit in our paucity of durable jargon, because we’re so much into the new thing. We don’t have enough shared experience accreted. We can’t say “here’s the term of art that correctly describes how to evolve your database,” to hearken back to the refactoring databases example. These terms are not coined, we have kind of a shallow language for what we do because we aren’t learning and collecting and collating these lessons as we go along.

Squirrel: Okay. Well, I’m now going to go read Joel’s comment, because that sounds fascinating. Thanks, Jeffrey.

Jeffrey: Thanks, Squirrel.