120: Expect The Unexpected with Andy Hunt

[Are you truly involved in the developer communities you work in and sell to? Are you seeing the value in the events that you are a part of? DevRelate.io can help. Developer and Community Relations as a service. We speak developer. Learn more at DevRelate.io or email us at [email protected].] AVDI: Hello and welcome to Episode 120 of the Pragmatic Podcast. I am Avdi Grimm. With me today is Janelle Klein. JANELLE: Uhm, I think it's Greater Than Code but thank you, Avdi anyway and I'm here with my good friend, Jessica Kerr. JESSICA: Maybe it's both because today our guest is Andy Hunt. Andy is one of two authors of the book, 'Pragmatic Programmer' and one of 17 authors of the 'Agile Manifesto.' He co-founded the Pragmatic Bookshelf and since then, he's written a whole bunch of other books, probably with lots of other authors but now, he's even writing science fiction. Andy, welcome to the show. ANDY: Thank you. Thank you so much for having me. Pleasure to be here. JESSICA: In case you didn't know, we are always going to ask you this one question, "What is your superpower and how did you acquire it?" ANDY: Ultimately, I think I have a knack for explaining the blindingly obvious things to people that sort of walk around and don't see, for whatever reason. Out of necessity, it's like, "Look, if you think of this this way or look at it this way, that's better and makes the world a better place." JESSICA: That's actually really hard because the blinding obvious things, those are like unknown knowns. ANDY: Right, to quote Rumsfeld. The problem is we all have a tendency to sort of go through life on autopilot, sort of with blinders on, just kind of doing our thing and you don't always notice when things have crept up on you or something's gone bad, your project has gone south or there's a problem in your house or your life or whatever because the change creeps up on us slowly. Back in the original Pragmatic Programmer book, we had the example of boiling the frog -- the boiled frog thing. Legend has it and we're careful to say 'back then.' We never have tried this but if you put a frog in a cold pan of water and slowly turn the heat up, it doesn't notice and it gets cooked. If you try to throw it in boiling water, it will jump out because obviously. As a species, we're like that in a lot of ways. Things just sort of creep up on us and it's a slow change and you don't really notice. A lot of times, whether it's something in software development or engineering or whatnot, I'll notice that here's this kind of consistent problem, here's this endemic problem. We know better -- with air quotes around 'know' -- but we still kind of fall for the same old traps over and over again. Back in the day, which had been in the late 90s, Dave Thomas and I were out doing consulting together and we noticed that a bunch of our clients, all of our clients really, had the same problems. We'd leave one client and go to the next and it's like, "It's like d�j� vu all over again. It's doing the same things wrong," so we got it in our head that we should just write a little white paper because we found ourselves telling the same little stories, explaining how the world actually works to folks, so we just write that down and make a little white paper out of it. Unlike every software project ever, it grew in scope beyond what we initially figured and that became the Pragmatic Programmer book, which to our shock and surprise, we've never written a book before. We had no idea how this works or what sort of tone to present or even what topics to pick. We both took a year off, if not a little bit more, from working and just worked on the book. That was probably, at least two and a half, maybe even three-man years full time working on the book, trying to figure out exactly that -- how do you explain the blindingly obvious in ways that people will really understand and accept and able to use? Things like the bullfrog metaphor, stone soup, talking to the rubber duck, the DRY principle, we came up with all these things to try to get folks in a better place developing software. I still do that. I'm working with some other guys currently on 'The GROWS Method' and trying to reintroduce the concept of continuous learning as a first class part of a method because -- JESSICA: And that's GROWS in all caps? ANDY: It is in all caps for no good reason, except it kind of look cool. JESSICA: Letters, they're growing. ANDY: They grow. They're getting bigger. One of the things we do there in workshops for folks who don't understand iterative or incremental development is have them play Battleship but it's a variation where you have to take all your shots upfront. "Here's all your pegs, just shoot, go!" and of course, they don't hit a damn thing. But then you explain why and you play it the regular way with feedback, where you make a shot and then, "Oh, I got a hit. I'm going to adjust my strategy now because I know I'm near something," and so that's a very hands-on, tactile, visceral way to explain that sort of feedback loop, where you can adjust your aim and get a better result. You can sit here and spout off abstractions about lean and incremental and iterative and scrum iterations and whatnot and yeah, sure we do that. They don't. They really don't. You explain it with a game or an analogy or something like that and they're like, "Oh, that's what you mean. I understand that now," and it's funny, just how the analogy of the words can make a difference. Pragmatic Programmer came out in 2000, by the way, so I'll let you do the math. That was a while back and one of the things that we talked about there was what had been known as a walking skeleton style of development or a thin-thread, where you develop some feature log-on or whatever but it goes all the way through the application -- from the screen all the way to the database, through whatever middleware, all the parts. It's 'Hello, World,' the entire way. It's skeletal. There's nothing real to it but you at least have a stub that goes through all the parts and then you grow that and the analogy that we used was like a tracer bullet in the old war movies, where you're getting real time feedback on what you're firing at so if the target moves, it's no big deal. You can just adjust your aim and there you go. Whereas if you got a more ponderous, plan-based approach, it's like shooting one of those big howitzers where you need a firing computer and you're measuring the wind speed and direction and you go to all these nonsense and by the time you've done all that, if the targets moved, you're out of luck. Again, it's a kind of a simple explanation but I've said this to executives and CEOs something like, "I never understood this whole incremental and iterative. I get it now. I don't know what the hell that crap is but I know what a tracer bullet is and I understand what you mean by that," and suddenly, they were in line. JESSICA: And the skeleton, is that like, it's not doing anything but the neck bone is connected to the neck bone, connected to the back bone? ANDY: Exactly. You've got all the parts, so then it's a much easier way to go in and flesh out those little 'Hello, World' level one line stubs and start to introduce functionality because now, you're just building on something that sort of already there. You're not staring at a blank canvas, to use the art metaphor. You're not trying to invent it out of nowhere and figure out where you're ends have to hook up. You kind of already got at least a first level approximation of that and then, it's much easier to grow it from that starting point. It was something that we've been advocating now for some decades because it works. AVDI: We keep trying to get back to this idea of iterative development and continuous learning. My understanding, even the paper that's usually cited as describing the waterfall model back in 1970 was saying, "This is bad. We need to be more iterative and we need to be more spiraling." Why do you think we keep coming back to the same mistake? ANDY: A lot of reasons. One of the larger problems, I think is the folks who happen to own a company or manage a company where software development wasn't what they were about initially, it's a foreign language to them. It's a very foreign concept. They try to understand it. These are popular metaphors you see about, well it's like building construction, you've got architects, and they build it and then the programmers come in and build it and everyone moves in and happily ever after and of course, that's false. It doesn't work that way. But you're going up against ingrained management and organizational and corporate structures and organizational theory that dates back to the 19th century. A lot of stuff that we do in 'corporate America' does its thing because that was needed for the trains in the 1900s. Everything goes back to something really old and not applicable anymore but old habits die hard and unless you have a really compelling reason to change, you're not going to and even if you do have a compelling reason to change, it's hard. This is the way it's 'always' been done. This is what you learned at business school. This is the way the accounting and tax structure is set up or how you fund R&D dollars or whatever. I'm not an accountant but there's a lot of real world inertia in these areas that you can't just change on a dime, even though you should and you need to. JESSICA: So the external systems that exist within are not set up for iterative software development. ANDY: Yeah and if I can actually use the word little 'a' agile, they're not agile. In fact there's a lot of things in corporate America that are very much the exact opposite of agile. You need an annual budget? You have to give me your annual budget. That's not very agile, is it? Because I don't know what's going to be happening in here a year from now. Try estimates. Estimate is a wonderful topic. I even hate the topic, even just discussing it. It's like, "We want to know --" JESSICA: But you brought it up. ANDY: I did. I did. In six-minute increments, how much staff you need and what you're going to be doing in six months from now or a year from now? JESSICA: Make up a story. ANDY: Yeah, exactly and it goes back to the underlying problem and the answer to your question is cognitive biases. We have a hard-wired need for closure where our brain says, "I don't care if you give me the wrong answer. I need an answer. I've got this little mental spreadsheet in my head and I need to know that this project going to take however long. Give me an answer." Fine, eight months. I just made that up. I absolutely have no idea but you go away happy because I've got a number. It's totally fantasy. There's no rationale behind that whatsoever but damn it, it's a number and it goes in the slot and everybody's happy until of course, eight months goes by and you realize, "This is going to take a bit longer." AVDI: Yeah, I remember projects where they would do that process upfront, they'd allocate the time and the budget and then they would allocate a whole bunch of charge codes for different phases of the development and basically, whatever you were actually doing, there would just be an email that went out at the beginning of the week that's like, "We've used up this charge code, so we're burning the next charge code now," and it was really just like a list of codes to go down like, "Which one are we burning this week?" ANDY: Yeah. It's absolute nonsense. There's no product value to be derived from that. There is no shareholder value. It's waste in lean terms. It's an absolute waste but some regulation, some by-laws, some accounting procedure, something somewhere requires that and so there you are. JESSICA: Can I bring this around, my favorite quote of the week? ANDY: Absolutely. JESSICA: My favorite quote of the week is Jean Baudrillard, a French philosopher and he said that the excessive fruitless search for total knowledge lead almost inevitably to a kind of delusion, at least his Wikipedia said that that's his philosophy, so good enough. But the point is if you're looking for answers, you will find the answers. They'll be wrong and what you'll get is delusion but if what you really need is a complete picture of how the world works, you'll construct one. ANDY: Yeah, absolutely and that�s part of the problem. One of the hardest things about doing a very effective agile, incremental and iterative style company is you have to be comfortable with uncertainty and that's really hard. From a psychological perspective, that's hard. We're not built that way. We want certainty. We want to know that this process works. I just paid a bazillion dollars to get whatever certified and all these consultants in this process and as a business owner, I want my software development process to be a Play-Doh machine, where you throw the balls of dough and at the end and you turn the crank and out comes this beautiful extruded shape. That's what I want. Sure, that's nice. I'll let you know the winning lottery numbers tomorrow, too but that ain't going to happen. It doesn't work that way. It is a process of growth, of exploration. A lot of the properties that we want to take advantage over are emergent from the system, from chaos theory. You can't go in and say, "Let's nail this down. Let�s productize this. Let's scale it." That's even better. We have this one wonderful working, sort of SEAL Team in our company that's doing great. We have to scale that up. We got 10,000 people and we have to scale that up to everybody, then work that way. JESSICA: Yeah. Copy the questions, not the answers. ANDY: Yes, exactly right. JANELLE: Andy, you talked about this inertia and why it's difficult to change but it also seems like there's a lack of templates or alternatives for how to do things differently. You know, we have these constraints, the things that we want to be able to predict the future and write things down but how can we actually go about doing things differently. What suggestions do you have for that? ANDY: Don't try to predict the future and don't try and write everything down. It's a flip answer but basically that. Again, as a species, it's nothing personal but we suck at prediction. We're terrible at it. We don't know that. There's a little bit of that Dunning-Kruger thing going on there. We think we're really good that we can say, "I know it's going to be happening six months from now, a year from now, whatever," and we can't. If you remember, we got kind of blindsided when Y2K came up and that was pretty obvious that that was coming. That was just a bit of math. We knew when Y2K was coming and all the code was going to break and that kind of took everyone by surprise, which is kind of sad but we got through that. But in general, the whole idea of fortune telling, of trying to predict the future goes much more beyond just trying to come up with estimates or any kind of resource allocation. That comes down to how we design code itself. So much ink has been spilled like blood over the years on how to make code extensible, how to make it maintainable, all these sorts of topics. Absolute freaking waste of time. Non-sense. Do not try to make your code maintainable. Do not try to make it extensible because by doing that, you have to engage in fortune telling. You have to try to imagine how it might be extended, how it might be use, what kind of maintenance issues are going to come up five, 10, 20, 30 years from now. You have no idea. JESSICA: -- it won't be in use, then. ANDY: Oh, you'd be surprised. JESSICA: We delete a lot of what we write. ANDY: And that's exactly what you want to do. That's the goal. You want to make whatever you're writing disposable. You want it replaceable. You want it like this needs to be easy to rip out and put something else in its place. That is where you get that kind of flexibility, where you get a better coupling cohesion, all the wonderful buzzwords. What can I do to make this easily replaceable? Because you really can't guess what's going to happen. If you had looked where we are today, in 2019 if you looked at the sort of early threat models of what people were talking about the internet back around the turn of the century early-aughts, this kind of wasn't it. No one really saw the rise of social media and Facebook or these sorts of issues. We had time with My Space. That didn't seem like a force that could disable global democracy by itself. JESSICA: Oh, yeah. ANDY: But things change and there's a lot of science fiction and speculative fiction where folks think about AI is going to do us in. It's going to be the next Skynet, it's going to take over and stamp -- JESSICA: No, we can do that on our own. ANDY: Yeah, exactly. We don't need the AI for that. What will happen will be something we don't see coming and that's that whole black swan phenomenon, if you read the book. It's an interesting notion that all the big changes that have come up in history were from things that basically you couldn't see coming because if you did see it coming, it wouldn't be a big deal. It's kind of QED. It's like it's the stuff you don't see coming. I remember I was cleaning the basement a couple of years ago when we were moving houses and I found a bunch of old magazines from the 90s thereabouts and every cover, all the opinion articles, who would win, Motif or OPEN LOOK? JESSICA: What are those? ANDY: Exactly and who are going to win --? JESSICA: No, seriously. What are those? ANDY: Oh, my God. X Window System, right? You had OPEN LOOK from Sun and you had Motif consortium which is MIT based. It's been so long, I don't remember. But you had these competing standards for GUI interfaces running on X Window for UNIX because that's where the action was sort of at the time. Like everything else, they were really sort of the same thing but they tried to look different and they were different. It was like Microsoft back in the day saying, "We're going to have pads but we're going to make our past separators go backwards from everyone else, just because," but this was a huge topic and then networking, who's going to win the networking wars? Is it going to be RMI or CORBA and the audience goes, "What?" JESSICA: The answer is no -- ANDY: It's HTTP1, the Web1, the stuff that no one really saw beyond the desktop metaphor or the workstation metaphor at the time that was computing. Clearly, one of these systems is going to be ascendant and take over and rule the world and now, the entire stack that's swept aside. They're going to be saying, it's completely different. If you're talking about desktop now, people were like, "What? It's mobile, dude. It's all mobile. Everything's mobile. Who writes desktop apps?" There folks that do but not a lot. JESSICA: Sure, internally in companies. ANDY: Not like the old days. AVDI: It seems like most prediction is pick a trend that you can internally see and then try to extend the line off into the future. JESSICA: Oh, yeah like Kent Beck says, "If your goal is like a 10X increase, picture a hundred times or a thousand times increase and ask, 'What would have to be true?'" ANDY: What fundamentally changes? This tangential but that's what I find interesting about science fiction, speculative fiction in general, is that sort of if this change happened, if we had this great technology, if we had warp drive, if we had transporters, if we had unrestricted gene editing, if we had AIs that were smarter than us, what would it be like to live in that world? JESSICA: Oh, yeah, tell us about your books. ANDY: I started, I guess two years ago now, writing some science fiction and I published the first novel, Conglommora which spells just like it sounds. There's two 'M's and it's about humanity screwing up the planet as we're going to want to do in most fiction and then heading out to the stars but then realizing that none of those Goldilocks planets that we had hoped for worked out. They all had issues that we didn't know until we got there. Notice the theme. It's just like software design or anything else that looks great on paper and then you get there, it's like, "Crap. That's not going to work out." They end up taking all their ships kind of to the edge of space and just hooking them together and that's it. This is our life now. This is all we got and then a straggler from Earth shows up and all hell breaks loose and it gets fun from there. I wrote a sequel to it, wrote the second book which expanded the story from the original one and then the third one -- I haven't started yet, took a detour -- to write a novel about a haunted house that set just after the second Civil War. That was kind of fun. This sounds really bad but literally, I'm not exaggerating, this Saturday, I was sitting in my living room, working on my novel, listening to the album I had just finished recording for February because there's this challenge. There's the RPM Challenge that you see on the web, they say, "You have one month to write and record an album from scratch, 35 minutes of music or 10 songs, your choice. You have to sit down and do this in one month," and the bastards chose the shortest month of the year and I hadn't done this for years. I've done it a long time ago and that was kind of fun but it's really brutal to try to get that creative and get that much of something completed in a time box fashion. I think, they do this with writing too. They've got the November Writing Month where you've got a month to, at least start a novel or try to finish it or what have you. There's a lot to be said about the panic of a time box. You've got a hard deadline. You've got this much time, you have to now make the hard choices. This really working? Nope. Ditch it. That's why I think scrum has become so popular -- bring it back around again to development. Scrum is waterfall. Let's face it. It's a short waterfall but it's still a damn waterfall. It's a two-week iteration. Now, if you're used to doing six-month, a year, 18-month iterations, it's a godsend. It's a miracle. It's absolutely amazing but it's really not. It's two weeks, 30 days, whatever is popular in this day and age. Again, as Avdi is saying earlier, the goal is continuous deployment, continuous integration, continuous development. You want to have some sponsor, executive come in in the morning and say, "I got this great idea. We need this feature. We need this thing," unless it's something really bizarre, you should be able to roll that out in a day or two. You should be able to roll that out that afternoon. JESSICA: Or some piece of it. ANDY: Or some piece of it or some early prototype of it. It shouldn't be weeks. It certainly shouldn't be months. The world doesn't work at that pace anymore. Even our concept of a project, we kind of view this like a Hollywood film. You get all these people together, you're going to blow a ton of money, it's going to take years and cost $30 million and then, it dips at the box office when it comes out. You talk about inertia. That's still how most people, I think view a project in software development. This is one big release after you've blown through all the money and then, you're done. JESSICA: When they act like it's done like a movie. Sometimes, your software is an ad campaign and it's up for three months and then it's done. That's kind of the only kind it's done. ANDY: Right. But otherwise, it's continuous. It's more like a series. It's like Dr Who. It just keeps going. You change out the actors -- JESSICA: -- with reincarnations. ANDY: Yeah, it just keeps going. Look at your phone. How many updates of apps you get on your phone every damn day. This stuff is just rolling out. JESSICA: -- slower than web apps. ANDY: Yeah, absolutely but they're not waiting because you can't wait. You have to be on top of the latest security holes that have been found on the platform, the latest attack surfaces that have been found, the latest regulations -- thank you GDPR on whatever else is going to roll out this next week -- JESSICA: With the latest changes to when daylight savings time happens? ANDY: That's a good one. That's fine. Talking about inertia, there's a remarkably stupid idea that we can't seem to get over. We're still stuck with [inaudible]. Why are still not using the metric system? JESSICA: Oh, yeah. My kids complain about that? Like, "What is wrong with this country, Mom?" ANDY: It became like illegal for us to use the metric system as of like the early 70s. I think there's like some global map that goes around the net. The only two countries that still don't use metric are like Rwanda and the US. That's it. I think even North Korea uses the metric system, for God's sakes, so yeah, you talk about inertia. That's a classic example. There's no real good reason not to accept investment in tooling, investment in training. It's the way we've always done it. It's what we're comfortable with. It's what we know. Those are powerful forces. JESSICA: That continues deployment is not just about things you have to do. It's not just about avoiding disaster with security or daylight savings time. It's also about expressing what we've learned and moving the dot and getting better and better. ANDY: Absolutely right. The biggest drums that I bang on, I think is to tell people about feedback, about the importance of context and about the importance of learning and they're all sort of tied into each other because one of the problems with formal development processes of any built agile or plan-based is soon as you start putting a hard and fast rules like that, you're ignoring context and that�s a really important thing. This is why 'scaling' agile doesn't work in a lot of places because you're ignoring the context, you're ignoring those ingredients that made those couple of pilot teams work great in the first place and say, "Now, we're going to put hard and fast rules. We're going to product ties that. We're going to lock it down. We have to lock it down." I've always hated that phrase because you don't want to lock it down. You want to open it up. JESSICA: They want to lock it down but that's not actually going to help. It's only going to feel good briefly. ANDY: Proceed that way. JANELLE: I'm thinking about these projects that I've seen where these teams got really excited about continuous and then they spent all this time and money in infrastructure on continuous and seem to forget what it was they were doing and why, for any kind of real purpose. I see that happen all the time where we get so obsessed with process, so obsessed with we need to make all these feedback loops and we need to do it the certain way and just losing sight of why anything matters at all anymore because we're so obsessed with that. I'm just curious, why should it continuous be the goal. ANDY: A couple thoughts there. Yes, we have an absolute tendency to want to become experts at the process, instead of experts at problem solving. I was at a shop a couple of years back visiting and they prided themselves on just how thoroughly and strictly they adopted XP and it was remarkable. It was a larger place they had, 150 to 200 developers, I think. Something on that order. It wasn't 10. It was a bit larger than that and they were so dogmatic about it, so rigid about it, that it's almost not an exaggeration to say, they had to sit down and have a planning meeting with story cards to decide where to go to lunch. That was kind of the level they were at. It's like, "The Indian places is takes longer than the Chinese place, so that's like three points instead of one point." You know, they were just totally out of hand and they went out of business. Within two or three years after that, they went out of business for exactly that reason. They had become ossified, calcified. They were so rigid in their interpretation of what's not supposed to be rigid in the first place that they were unable to adapt and penultimate goal is to be adaptable. But when the bunch of us got together and made the Agile Manifesto, there was a lot of discussion about what to call this nebulous concept that was floating around and in fact, when, I think Bob Martin booked the facility, it was booked under Lightweight Process Conference. It was what we had called it. There was only 17 of us but we called it the conference for tax reasons but we didn't know what to call it. Some folks want to call it 'Lightweight' to get away from the sort of ponderous approach of ISO or these other waterfalls kind of things and I think we maybe did a disservice by settling on agile, I think adaptable, might have been a better word. I think that's a better connotations because really, the whole nature of the game is you have to be able and excel at adapting to change because change is coming at us so rapidly from society, from technology, from every corner really. If you look historically, today's pace of change, as fast as it is, is the slowest it will be in humanity. It's monotonically increasing. It just keeps getting faster. Adaptability is where it's at. That's the goal in a very Darwinistic sense. If you don't adapt you die. It's just that. But the thing is you've got these things that you have to adapt to for survival, security, legislation but the real goal, the actual ultimate goal is to serve the user and that's the important part. This is what folks lose track of when they start getting all bent on we're going to master this process. I don't give a fig what process you use. I want you to serve my needs as a user. Interesting that I find, it's the same thing if you are writing a fiction or writing technical books or if you're writing software, it's all about the reader. It's all about the user. It's not about you. What you put in the big headline is it's not about you. JESSICA: So, Janelle, you are pointing out that you can continuously deliver all day but what are you delivering. Continuous delivery can help you survive but we also want to thrive and that means serving the user. ANDY: Exactly and that�s where you need to be able to adapt quickly and do what they need. You can see that there's all these great examples of large companies who aren't adapting quickly well. Banking seems to be in a bit of a trouble these days. There are some well-known, very large companies who are willy-nilly having huge data breaches, having data center outages, having all these manner of user-facing difficulties, scamming their users, getting called on the carpet for by Department of Justice, there's all kinds of stuff going on there and again, you have to serve the user. Two of my pet peeves: banks and credit cards in particular. First of all, you're sitting there and trying to balance your statement, so you get the email, your statement is ready. I click on the link, how many damn clicks does it take for me to get to my statement? JESSICA: First, you have to answer two security questions that anyone you went to high school with you but no. ANDY: Exactly and all of my neighbors who know the name of our pet. That's like in that cartoon saying, "It's your first pet, kids. Pick the name really carefully --" JESSICA: So, your first pet is like 6C4# -- ANDY: Yeah, exactly. We call them 6C for short, yeah. JESSICA: But the neighbors don't know the rest of his name. ANDY: Yeah, right. You go through that nonsense, you have to go through, at least four interstitial pop-ups, advertising some bilious crap that they're trying to push on you that you don't want. Now, you finally get to their interface and is this month's statement, any sort of a button anywhere up on the first page where you can see it? No. You've got to go through some programmer's hierarchy and I swear to God, half the time is mirroring the database. You can picture the schema from their UI because this is under this, this is under this, this is under that and you get in and you finally get to the bloody thing and then you look into that, you're looking at your other stuff, looking at your records and oh, you didn't touch the button long enough. For your convenience, we log you out. It's like you're outside in the yard too long, so we lock the house for you as a convenience. Yeah, thanks. Appreciate it. AVDI: I feel like there's almost a paradox here because it's vital to be adaptable. I�m hearing it�s vital to be adaptable, even practices that we adopt become part of being a nonadaptable. They become something that we get locked into. Do we need rigid standards of adaptability? ANDY: No. That's an interesting concept. Rigid standards of adaptability, yes very strict. That's exactly the problem and this is one of the things that kind of really galls me too. It added to a long list. We haven't even got to telemarketers yet. The Agile methods, by that name have been around for 20 years, how much have they adapted and changed? Almost none. You know, some little tweaks here and there, maybe a practice or two but overall, they haven't changed and this is a different world than it was 20 years ago. Twenty years ago, we were talking about Motif and OPEN LOOK and CORBA and RMI and shrinkwrapped software development and desktop computers and slow net access and -- JESSICA: It was a different problem situation. ANDY: It was a totally different problem surface. It was a different environment. Almost everything about it was different and yet, a lot of our languages are the exact same. Some of them made some progress, our methods. The ones that we've been set as a goal, it's like, "We really want to try and do this," they haven't changed and they probably should have. I think there's a lot of value in saying confidently, any practice even the ones I advocate, that's not important. The practice is not important. The overall workflow and I prefer the word workflow than the process because you're actually trying to define how we work together as people and how we parcel out who does what, when we're doing it, how we're coordinating it, that's what a 'process' should really be. It's not the Play-Doh machine where you turn the crank. AVDI: If processes get ossified, is there a metaprocess that -- ANDY: Yes. AVDI: Or is there a culture element to this? ANDY: Both. There is a metaprocess and it is cultural in nature. What you have to get to and this is what I always thought agile, with a little 'a' meant and it doesn't mean scrum. It doesn't mean safe. It doesn't mean any of these ossified kind of situations. It means being adaptable, so what do we do to be adaptable? We have to be really good at seeking out and using feedback. We have to be very aware of the context that we're working in. "This worked great for the last three projects. This one's different. It's not going to work the same." We have to experiment and find out what's going to work good, get the feedback from that in this context, learn from it. It's like I'm using the same five words over and over again here. It's feedback, it's context, it's learning. That's the sort of metaprocess, if you will. That's the kind of stuff I was trying to pitch with the GROWS Method Ideas, was getting away from these very strict idea of processes of we're going to have a stand up meeting for 15 minutes and these are the rules and here is the questions you have to ask. That's a great start. Don't get me wrong. That's a great start and if you haven't done that kind of thing previously, that can be a real boon to get you up to the next level but it only gets you to that next level. To go beyond that, you've got to go beyond that and you've got to start figuring out what you might do better in your particular context, in your situation with the skills that your team has, with the problems unique to your organization, your users, you've got to get up to that level of experimentation and then analysis and trying it out and then trying something better and learning and stepping from there. That's where it boils down to. JESSICA: I think that in design -- design of workflows, design of architecture, design of software -- we need to stop asking first what is right and ask first how do we change it? ANDY: How do we change it is a really good answer. Recognizing what's wrong is more challenging sometimes than it seems and once -- JESSICA: Sometimes it's blindingly obvious and we're blinded by it. ANDY: Yeah, you know, we can't possibly change that. We can't do that and as soon as you say that, you're right. It's kind of a self-fulfilling prophecy there's. It's like, "We can't possibly change it." Okay, well, there's no law that says that you and your company has to survive. That�s not a requirement. JESSICA: Well, in most companies, yeah. ANDY: That'd be nice but if you do it wrong, you won't because it's that simple. Martin Fowler had a great line some years back. He said, "When you run into these sort of really stiff opposition from the organizations as we have two options. You can change your company or you can change your company." JESSICA: You can temp out of the pot. ANDY: Yes, like the frog. AVDI: Are there things that -- I'm hesitate to use the word practices but are there something that -- JESSICA: Exercises. AVDI: -- make a group more reflective? ANDY: Yes. There are. To make a group more reflective, you need a couple of things. You need cultural changes to make that acceptable. You have to have an environment of psychological safety. You have to have that kind of ability to look at stuff. You need to have opportunity. One of the things that I pitch with the GROWS material is that there's really three things you have to schedule. You have to deliver, you've got to have whatever next piece of functionality but you also need time to discover. You need to be able to experiment with the next tech stack, look at alternative design options, that kind of stuff and you need time to refine. You have to be able to fine tune and improve the development process. Everyone has been saying for years, "Yes, you should have project retrospectives or postmortems." I always love that. It's like, "Postmortem, it's too late." Patient is dead, this is not going to help you for that project but it's not for free and this is part of the problem. You actually have to invest in it. You need to invest time on the calendar to both deliver and discover and refine and if you give short shift to any of those, then that's going to come back to haunt you, one way or another. Maybe, you don't do all three every day or every week but there's got to be time for it or it won't happen and so, that's what ends up happening. We're so busy drowning from the rain. There's no time to go and plug the roof. JESSICA: I usually say that, [inaudible] have that 80% or 20% time thing where you could work on whatever you want. I think we should spend 80% of our time like using the system that we've built and delivering within it and the other 20% improving it. ANDY: Yeah and that's a great idea. Again, we pitched that back in the Pragmatic Programmer book, that if you're working on a project, you should spend like a week with the user for that area of functionality. You should spent a week with them doing their job, watching how they do it. Because there are some well-publicized failures where that didn't happen and the sort of hubris and arrogance on the part of the company or the developer is like, "We know what's better for you. We're going to build this thing," and it turned out that it wouldn't work at all for whatever reason. The target community was illiterate or didn't speak that language or they didn't use it that way. Travel agents was a great example back in the day. They were used to an old character-based system where they would just spit out these 20, 30 character command line strings to get what they wanted and then it first gave them the point and click things and were like, "What the hell is this? I can't --" JESSICA: It was so slow. ANDY: Yeah. It slowed them down. It cracks me up to this day. If you go to the Android or iOS keyboard and it's QWERTY. It's a QWERTY layout keyboard on a piece of glass emulating the physical keyboard where they shuffle the keys around to slow it down, so the keys wouldn't jam. You talk about inertia, I mean, come on. JESSICA: But that's okay. There's a usefulness to that inertia because that keyboard exists to serve a user who is familiar with the QWERTY keyboard. The familiarity there in the wider world makes the QWERTY keyboard on the phone efficient in that situation. ANDY: Yeah, maybe. I ain't buying it. JESSICA: But travel agents, if I sat down in that old command line system, I would not be efficient but they were efficient in the situation of the travel agents who knew them. ANDY: And this gets to the other really major point is one size doesn't fit all. Every application should have the expert user mode and the newbie mode and this makes me really insane, especially with a lot of the direction Apple's been going in lately. They have really cast off for writing anything for experts in their media apps, in their OS. They're really targeting the introductory, beginner, novice level and kind of keep dumbing it down. Apple's keynote started throwing away features that if you're a professional presenter, you relied on it. They were just like, "We don't need this anymore. We'll just quirk them off." JESSICA: Well, that's the alternative. You get Microsoft Word with the ribbons with thousands of buttons on them. ANDY: That no one ever uses. That�s the tension. You want to be able to provide for different audiences in a reasonable way. For Word, as an example for something like that, we've got a big menu system, how different is UX? I just need to write a memo, just give me open, close, bold and italic and shut the hell up about everything else -- JESSICA: Give me a command line. ANDY: Yeah, give me a command line and then I'm actually typesetting my thesis or my book and I need control over the widow or orphan breaks. I need whatever the finer aspects are but this is a huge problem. Not just with these particular applications but with a process adoption in organizations, one size does not fit all. You will have experts. You will have novices. You will have everyone in between and they have radically different needs. JESSICA: Almost like each team has different needs. ANDY: Isn't that amazing how that works? JESSICA: You talked a lot about the journey of companies and software. Tell us about your journey. Y2K wasn't even halfway through your software career. No, it's more than halfway. It was whatever sounds plausible. ANDY: It was a long time ago, so we just leave it with that. My journey was, I think kind of interesting. I was in grade school, I guess maybe junior high when I stumbled across a book at Radio Shack -- you remember Radio Shack -- and they had a book about the coming microprocessor revolution and large scale integration and the promise of the LSI chips and all this amazing stuff. I was just a kid, I read that and I was like, "This is cool. I want to do this. I want to be involved in this," and we had a teletype at the school that was hooked up to a mainframe with an acoustic coupler. It's just like -- JESSICA: Is that like a modem? ANDY: Yeah, it was like a modem on a phone handset. I explain to my kids once. It's like a modem on a phone handset, you put in the cradle and they're like, "Dad, what are you talking about?" JESSICA: Yeah, what is a phone handset? ANDY: Yeah, what's a phone handset, let alone what's a modem? It gets hard but we still dial a phone. People talk about dialing the phone. I know people who talk about dialing the phone. We don't have had dials in however long, it's like about rolling down the car window -- JESSICA: Oh, yeah, we do say roll down the window. ANDY: -- car that actually that had a crank, so old habits die hard. I was into tech at an early age and got a bachelor's degree in computer science and all sort of stuff. I worked for a couple really big giant companies, realized I didn't want to work for big giant companies -- JESSICA: How long did that take? ANDY: That's only a couple of years at the big behemoths and then, I worked at small companies doing graphic software that was used in special effects work in Hollywood and that was actually really cool because one of the companies hosted us -- we're out of a [inaudible] out in California and some of the vendors that we use were the big special effects houses in Hollywood. They threw parties for the developers at Prince's nightclub in LA and -- JESSICA: So you got to be a rock star. ANDY: Yeah. Billy Idol came and gave a private concert to 150 of us. That sort of thing. That was an awful lot of fun. I kind of missed those days and then, I started consulting and going out and seeing just how screwed up the rest of the world really is. It's kind of one of the things about programmers, like you sit there in the kind of pristine beauty of an algorithm or some really beautiful code that you have or you just discovered some really neat language framework or this is mathematical precision and beauty and calm to it and then you walk out of your office and you've got users drinking from the bottom of the glass, like that cartoon and all the insane management nonsense and insane politics and the real work in all its messy grandeur. I experienced all that messy grandeur for some years as a consultant and then started the writing thing, as I mentioned in the beginning sort of by accident. Dave and I wanted to write a white paper for our clients, so they would screw up a little bit less and get them a little bit onto the idea of here's how you should use a version control system. You should have automated bills. You should have unit tests. You should think about problem solving this way, all the things that are in Pragmatic Programmer. It was shortly after that, two things happened. We wrote the first Pickaxe. We wrote the Programming Ruby book and that was the first English language book outside of Japan on Ruby, which helped bring it to prominence and again, we wanted it for ourselves. We want it like a little reference book. It was going to be a short 50, 80-page guide to Ruby and the first edition of that was, I think around 250 or 300 pages, something like that. The current version, Dave updated a couple of times and then [inaudible] but it's up to 850 -- JESSICA: Oh, my God. ANDY: -- I think. It's a doorstop but it needs to be. JESSICA: But words are cheap now on the internet. ANDY: Words are cheap on the internet. We wrote the Ruby book. That's around 2000, 2001. That's when the Agile Manifesto. Dave and I were two of the 17 and we got together with the other folks and wrote that because again, a lot of the stuff that we had promoted in Pragmatic Programmer was very much aligned with what Kent Beck was writing about in the first XP book, which had come out at that time with what Alistair was doing, what the scrum guys were doing. We're all kind of floating around in the same -- JESSICA: Was scrum a thing that long ago? ANDY: Yes, absolutely. It predated that even and that's kind of the other funny thing. You look at the Agile Manifesto or anything that was wrote at the time, none of that was new. There's pictures of pair programming going back to the 50s with people who [inaudible] -- JESSICA: There's kind of a magic soup to it when you put it all together. ANDY: It is but all the ingredients were there forever. If you look closely, there's that famous picture of the first bug, the moth tape the log book that the Grace Hopper's organization found and if you look at what was in the log book, they were running unit tests of the sine and cosine tables and that was... I forgot what year that was. That was late 40s, early 50s, that's absolutely ancient history. JESSICA: We've been doing that forever. That is an old idea. That idea has been around since the 70s. Yes, so it has everything but everyone, including stuff like the Agile Manifesto, including stuff like Kent's XP book, everything that brings an idea to more people that makes it accessible to more situations, that's new too. That's a contribution. ANDY: It is. JESSICA: It doesn't need to be original. You don't need to copyright it. You don't need to put the personal story in front of your recipe but anyway. ANDY: Exactly that. I feel kind of bad in a way that I've been saying the same things for several decades of my career but again, it's an ever-changing, always new audience that hasn't heard it before or heard it and forgot it and needs to hear it again -- JESSICA: And it's ready for it now. ANDY: And it's ready for it now. You could say the same thing about the diet and exercise industry. There's a simple message: eat less, burn more. That's all it comes down to and telling people what practices to follow to do that, what process to follow to do that, what recipes, what ingredients, that's how many billion-dollar industry. It is absolutely huge and you can sum up the nutritional aspect of it in a paragraph but it's not that easy to do, is it? JESSICA: Yeah. It's something else to bring the idea into the world and everyone that we talk to, all the different companies and the different organizations, they're not all in the same place and they don't exist in the same situation. Their users aren't the same, their corporate governance isn't the same. It's okay to be behind what people tell you is state of the art, if you're moving. ANDY: Yeah. It's not even behind. You are where you are and that may be, exactly where you need to be. Maybe you need to be ahead, maybe you need to drop back a little. One of the things -- JESSICA: Maybe you need to go slower. ANDY: Absolutely. One of the things that we did with the GROWS stuff was capitalizing this idea or exploiting this idea that one size doesn't fit all. The practices are sorted by skill level, so there's novice level practices and then it moves up to advanced, beginner [audio glitch] because you've got different needs at different skill levels as an individual. As an organization, as a team, you have to treat things differently. You have to handle things differently. Take a simple example, maybe aversion control, maybe the novice level aversion control of using git, you shouldn't use branches. You get yourself into trouble on it. Maybe you should concentrate on this, concentrate on that. You've got different requirements at different levels and as an industry, I think we tend to ignore that a lot because the thought leaders -- JESSICA: And like berate people. ANDY: Yeah. You should be doing this advance practice that you -- JESSICA: You are [inaudible]. ANDY: Yeah and it's kind of funny because not everyone gets hung up on those things. We have to have this big, massive, giant Java stack and this huge data center and the kid down the street just wrote something in PHP in an afternoon that will kick your ass. That�s the world. That's how it goes. JESSICA: Yeah. There's a lot of levels of good enough and wherever you are, you can move forward and you don't have to feel bad for not being where somebody else is. ANDY: Absolutely. The only thing you should feel bad about is if your users need something and you can't give it to them, then that's something you need to look at and we have to address that. JESSICA: Also, feel bad about it if you're not learning. ANDY: Yes. JESSICA: If you think you know how it works, that's the worst. ANDY: Yeah, you've already lost. JESSICA: Yeah. If you want an answer more than you want to learn and get closer to the right answer, then you dig yourself in a hole. ANDY: Yeah, as you say, if you want an answer, you'll get one. It's just may not be the right one. JESSICA: And even if it is, it won't stay the right one. ANDY: And that's the important thing. I think being in this industry for this long, this many decades and seeing that, nothing last forever. You look at some great tech, some great tech stack, some environment, some legal problem, whatever, that's all temporary. JESSICA: QWERTY will be here forever. ANDY: Yeah, it won't. Interesting, I'll make you a bet right now. QWERTY will not be replaced with a Dvorak layout or anything else. It will replace for something that's not a keyboard at all. Voice or you stick that jack in your temple or whatever it is -- JESSICA: You breathe on the phone. ANDY: Yeah, it just reads your thoughts from your eyeballs or you just ask the NSA. They know what you're thinking anyway, so they'll just take care of it for you. You know, whatever it is, it's not going to be who wins QWERTY or Dvorak or whatever else. No, the whole thing -- JESSICA: It's not going to be an 'or.' This will not be the only option. ANDY: It'll be something completely different. JESSICA: Speaking of something completely different, I think it's time for reflections. At the end of the show, we'd like to do reflections where each of the panelists goes back to something earlier in the show that they thought was really interesting or brings out a point or a link that we didn't quite get to and then we usually let the guest go last. Janelle, you're super quiet. Do you have a reflection? JANELLE: Yeah, I do. I've been sitting here a little bit annoyed obviously because I am thinking all of these things really have tradeoffs and are not really that clear cut and so, if you take just for example, this idea of you should feel bad if you can't give the customer what they want -- they want something and you should feel bad about that -- and I see that as another anti-pattern that companies get into, where they turn themselves into a consulting company that is masking as a private company and try to do anything and everything and then run themselves out of business because they're trying to do everything the customer wants, right? I think it's just as important to be able to narrow down and choose a focus and identify what is the problem we're solving as part of that and it's really easy for continuous to be the goal and for learning to be the goal and then, we end up in this whole new set of anti-patterns that are doing lots and lots of learning but not learning the right things, not reaching the breakthrough insights that we need to build a successful business because again, it becomes kind of an obsession around the mechanics of the process -- the mechanics of continuous -- as opposed to figuring out the balancing act of how do I build a successful business. How do I make decisions when I've thought these really hard challenges and constraints with I can't predict the future. If I just accept that, how do I make decisions about how many people I should hire for my team, you know? You've got some aspects of things, some aspects of decisions that are hard to make which is why there's a push for predictions but we need to have alternative ways and methods for making those decisions and I think, we need to shift from a place of bitching about the constraints of the world to figuring out strategies for solving these problems, figuring out templates for alternatives, setting up alternative markets and economic systems that can support alternative ways of working and we're in a place now where these constraints are holding us back and I think we're also in an era that it's going to take some collaboration around leadership in the lessons that we've learned over the last few decades to move beyond where we are right now, like changing faster agile is not enough anymore. JESSICA: Yeah and speaking of building a better business, that's a lot harder to talk about. We can't sit here on a podcast and blather about how you can make your business better because talk about context. ANDY: Exactly. JESSICA: Yeah. ANDY: I just wanted to throw a few thoughts in there. It's probably out of turn but -- JESSICA: Also, thank you for saying that you're annoyed. That was -- ANDY: Yeah, absolutely. Two things: you're absolutely right. Any kind of advice that you give any corporation or any individual, they can take to the extreme and do bad things with it. They can fetishize the process. They can just go the wrong way. There was a hilarious example of that in the Pragmatic Programmer book. We said, "It's a good thing to use metadata outside of your application," so if you have to change business logic or adapt to something, you don't have to recompile and reshipped the software. In the tech of the time, you can just go change the metadata. In general, that's a vaguely good design ploy. It's a useful thing to do, until I came across the company where they took it to heart and made themselves 44,000 configuration variables for their application. They had 44,000 config variables because they wanted everything to be in metadata. The punchline is they had 17 customers. JESSICA: But they didn't repeat themselves. ANDY: Didn't repeat themselves. I absolutely hear you. You can give the best advice in the world and it is absolutely possible to run with it in exactly the wrong direction and screw yourself up. The other thing I just want to add in there was you talk about tradeoffs, that is a huge topic that I wish got more airplay because engineering is about tradeoffs. You hear people argue about this is the best language or the best framework. That's nonsense. Best for who? Best when? Best in what? Best practices -- I hate that term. Best for who? Under what circumstances? There's no best, there's no good, there's no better. There's 'here's the trade off, here's the consequences.' That's what it comes down to but we tend not to talk about the things that way. We tend to, "This is the best framework for the web or this is the best language for this or this is just the best language. Screw the rest of you all." Sadly, it's a very popular sentiment and it doesn't work that way, right? JESSICA: Yeah, because we like to talk in absolutes and we think that we can either know something or not know it but it's not like that. As Janelle said, we can't predict the future. We can't know everything about the future. We can't give an accurate estimate of a number but we can know something. We can know propensities to some degree. We can estimate in a range and then we can choose whether to spend time researching to narrow that range. These things are not binaries and every piece of advice is in response to a problem situation. As soon as you use it, your situation changes and that's probably not the best advice you need anymore. ANDY: Exactly, right. To me, it really comes down to for these things that we don't know or we don't know enough of, you have to experiment. You have to try it. Is this the best framework to use? Well, I don't know. Let's try it. Let's try a little half day prototype and see how it goes. It's 1:20 here in the on the East Coast, so probably eight new JavaScript frameworks just came out this morning. Yeah, that seems about right. Which one is the best? Which one is good? Which should I use? I have no idea. I can't tell but I can try stuff. Let's try it out. Let's experiment. Let's see in our context, with our people, with our skills. Let's try to see if this works for us. AVDI: I think the thing that has stuck out to me is just the importance of slack time in any team or organization. When we were talking about the importance of having time to try stuff, again it was just talking about -- JESSICA: The slack with a lowercase 's,' right? AVDI: Yes, not the tool. Time to reflect, time to try stuff, time to talk about what worked, what didn't. I think the 20% time sometimes gets chopped up as like this is what it takes to keep programmers happy and what I've heard in this episode is this is what's essential to keep a group adaptable. JESSICA: I really like that. ANDY: I like that. That's a good summary. JESSICA: Andy, you had some reflection on our reflection but you have anything, apparently that you wanted to touch on? ANDY: I think we sort of recapped all of the high points but experimentation, learning, context, feedback, rinse and repeat -- those are the keys. You actually have to schedule time for that. That's something I really can't hammer enough. If you say, "Oh, we'll do that when we have time," you know --? JESSICA: Huh! ANDY: Yeah, exactly. It's like exercising. I'll go to the gym when I have time or I'll go for a run when I have time -- JESSICA: -- We're not ready yet. ANDY: Exactly and that's the other half of it. It's like, "Oh, I'm not ready for that yet." Well, you never are. You just have to jump in. That's how you get ready for it, you jump in and you try it. That's a very important point. All those things. Let me give you a handful of URLs of where to find me out on the wild web. I am a publisher in chief at the Pragmatic Bookshelf, where we have... I don't know how many hundreds of titles in print now. Everything from Agile to languages, Elixir, Phoenix, Ruby, Rails, Rust, Elm, you name it, we've got it. All the good stuff at PragProg.com. My home page is Toolshed.com and you can find links there to my novels of the Conglommora series, the upcoming one that doesn't have a name yet and when I finish the album that I'm currently mixing, I'll put a link for it there as well. The practices that aren't really practices but you really need to do so you don't fail and how to grow and succeed is all at GROWSMethod.com and there's a mailing list there which is currently sending about one article a month. It's very low volume but we have a ton of practices up on that website where you can click through and it tries to describe 'Here's how you do a thing, here's how you know if you're doing it well, here's the context in which this might work, here's the warning signs to watch out for if you go too far.' As Janelle was saying earlier, it's like how do you stop people misapplying this, well, show them some of the warning signs. "You know, you're doing this wrong, if..." here are the symptoms. We try to do some of that there as well to try to help adoption. JESSICA: Sweet. AVDI: Andy, thank you so much for joining us on this episode of Greater Than Code. I mean, the Pragmatic Podcast. I mean, Greater Than Code. JESSICA: Greater Than Pragmatic Code-cast-pod. AVDI: Yeah, that. ANDY: Thank you all so much for having me.