Test & Code| Episode 32:

Agile vs Agility, Dude’s Law, and more

David Hussman

Brian Okken: Hello and welcome to Test & Code. I'm excited to share this episode with you. On today's episode we have David Husman. David is a coach for Agility, an excellent speaker and runs an agency called DevJam. I learned of David while researching for a PNSQC conference talk. He presented a talk in 2015 titled, "How to Build the Wrong Thing Faster and Learn From It", and it's an incredible presentation. Today's interview is a wonderful discussion where David and I look back at all we've learned in XP/TDD and other Agile methodologies, where things have gone awry, how to bring the value back and where testing fits into all of this. There's a lot of great discussion here, I hope you enjoy listening to it as much as I enjoyed putting this together.

We don't have a formal sponsor for this episode, but I'd like to thank Patron supporters for encouraging me, sometimes with strongly worded tweets, to put out more episodes. Also thanks to Michael Kennedy for helping with editing costs. You can thank him by visiting training.talkpython.fm and perhaps leveling up your Python skills with a course or two.

And last but not least, thank you to everyone who has purchased either a digital copy or a physical copy of Python Testing With Pytest. I've been told by many that it's a quick read and improves their testing practices more with every chapter. Now onto the interview.

Welcome to Test & Code, a podcast about software development and software testing. This is the Test & Code podcast and today we've got David Hussman. For people that are not familiar with who you are, who is David Hussman and what do you do?

David Hussman: It's probably one of the questions I answer more poorly than others, but I suppose, who am I from my geek perspective is I got into programming early on, I started programming in the early 1990's. I was banged in a way almost 10 years, before any of this Agile stuff sort of crossed my radar. I worked at this really cool small company, there were about 14 of us, we did medical device work, we did early GPS stuff. I did digital audio stuff, and then I went to work in a big shop in Minneapolis, my friends convinced me I should go make more money. Then I suddenly was in with all these people and it didn't seem like anyone knew what they were doing.

Because there wasn't like first principle engineering and I read Kent Beck's White Paper. It was actually I think even before "Extreme Programming" book came out and he and 02:39 were doing all these cool stuff at Tektronix. And I thought, "Well, that reminds me how I used to work," and that's sort of where I went from being a full time programmer to like tech lead/coach. And when I published a few papers I got invited to the second XP conference in Italy. That was an awesome conference, it was about 200 people, but everything was on the table, I mean there were no methodology, sponsorships, there were no certification programs. It was a bunch of people most of which were I would call "makers"  many people call them programmers. They were trying to figure out how do things differently and better. And so for the last 15 years that's what I've been doing with people under the name of the Agile. The word Agile has taken sort of a dark trend for me in the last few years because it's become such a commodity. But I love making stuff, it turns out for the last chunk of my life I've been doing that with programming.

Brian Okken: Okay, your company is DevJam, is that correct?

David Hussman: Yeah.

Brian Okken: How did it grow into you being a team lead and a coach to having a company full of coaches and whatever else DevJam does?

David Hussman: Yeah, for sure. My business cards say David Hussman XML businessman. What I love doing is working with people, working on things. I've never really been sort of like a drive by, "You should do this and you should do that". I think people value when you sit down with them, so I would sit down and especially early in DevJam, I was still programming quite a bit. And they would be, "Wow, that's really cool, do you have more people like you?" and I would be like, "Sure," and I ended up just having friends come and work with me. And then I had some of those friends that were pretty strong tech leads, who also had maybe leadership skills and then they started doing some coaching stuff for me, and that's sort of how the company grew up.

Brian Okken: Nice, okay. You're careful to, I was looking around, trying to refresh my memory of what else is here. I had written some notes, and before we started recording, I had mentioned to David that I ran across who he was because I was asked to talk at a conference called the Pacific Northwest Software Quality Conference, it's in Portland, and I had spoken in 2016\. And in 2015 David spoke there, so I just had picked his video at random just to try to see what it was like to talk at this conference.

It was a talk called "How to Build the Wrong Thing Faster and Learn From It", and it's a great talk, so I'll put a link in the show notes. One of the things I liked about it just was the title, because that's what I think of as Agile development is how to build the wrong thing faster and learn from it. And you're careful on DevJam to not use the word Agile too much, even on your Twitter profile, it says coaching and developing Agility. So why the separation of Agile versus Agility?

Davis Hussman: Probably the dumb answer is me trying to make some significant standards or something. Realistically, I think when something gets a name, then it's easy for people to claim the thing instead of the behavior associated with it. And that's true with like music movements, philosophy movements, art movements, religious movements. I was thinking like Monty Python’s The Meaning of Life, when they say, "I'm not part of the Judean's people's front, I am the people's front of Judea". This is the most absurd kind of thing, like who you're associating with, and so I think democracy turns out to be a hard thing to practice. Because fundamentally, you have to be ready to talk and work with people you disagree with. To me, that's part of democracy.

So Agility is not "I am Agile" and this could be just my allergy to it, but it's interesting if you think about, like people say, "We're doing Scrum, we're doing Agile," and in English, the only time we typically use that kind of language is when we're doing something that is discreet, "I did the dishes", "I am doing the laundry", "I mowed the lawn," they are done. Einstein would have never said, "I've got to go do some physics," because it sounds stupid, because science is the nature of understanding. I like what you said earlier, what is upsetting for me or disconcerting sometimes is that people now are doing the same thing they have with every methodology— they assume because they're doing a methodology they are successful and that's sort of never been the truth with the spiral methodology or structured programming or unified process. And I like that you liked the name of the talk because I always feel like this Agile stuff has been helpful because it helps me learn.

And usually the dimensions of learning might be learning about people, learning about teams, learning about product, learning about technology. And people and products tend to be more difficult than technology and processes. I think that many people are still too sure that because they're going the stuff done, they are being successful. There's a lot of people in the Agile space that I think are frozen on measuring progress instead of product, or product learning.

Brian Okken: That's good. I did glom onto it a little bit because in the past few years, trying to understand— I was definitely affected by Kent Beck and his writing and XP and Test Driven Development, but I think I got it completely wrong. What I learned was something different than what is being taught right now. We had a barbecue just the other day for 4th of July and I had a couple people that came that work in IT world, which I don't, but they were both lamenting that Agile was coming to their companies, so they couldn't remote work anymore because Agile is against remote work. And I'm like, "How? There's nothing in the Manifesto for Agile development or anything there that says people can't be in different places?" So they're just being told that they have to change their behavior, not end a process, it is just a different process, but it's still like holding up process up on a pedestal.

David Hussman: Or they're being told to less comment, they are being told how to do Agile, that's not how you do Agile. I was joking that people often mistake crowds for collaboration, just because people are sitting together it doesn't mean they like each other and they're going to do great things. But people that do have a good mindset and are good people, when they sit together, there is less of the barrier of communication but that doesn't mean you can't work in different locations. That's a classically stupid at the end of the bucket of stupid things said in the name of Agile.

Brian Okken: So, one of the things that I'm having to try to come to grips with, and I'm hoping you'll help me with this, is I've probably been not fair but blaming the consultants for where Agile came to, and yet I admire some of your speaking. How is somebody that's got a consulting company not— you're fighting a battle I guess.

David Hussman: I like your opening line, "Blame the consultant", it would be such a good T-shirt, blame the consultant. I don't know, again, when I started doing this, I wasn't a consultant. I was a tech lead and I had a small team and Java was new, and I drank all of the sun Kool-Aids, and I looked at all those pictures sun cooked up. And then we started using it and we ran in all of these weird problems, and some of the problems we smoked out with test driven and automated tests. And our team had this data model that was trying to come up with the super-uber data model for retail in Oracle and it would just break our stuff all the time. As soon as we had continuous integration and test automation in place, we just went from stumbling around the dark to just knowing where the problems were faster. And so I wasn't, as the tech lead on that team, looking for a methodology, I was just trying to be a better leader for the people I was working with. Which is why I think, we're during a Tektronix, they are just trying to work in a better way.

Then I was with Ward one time I was kind of like stitching to him, so I was saying, "Ward, are you sort of bummed out that like what people have done with this neat thing that you guys came up with?" And Ward said to me, "I don't know if we'd be here, David, if it weren't for Scrum." And I almost like threw up in my mouth, I was like, "I can't believe you just said that." His point was, and this is something I've always struggled with, the vast majority of people I think need to have a name for something when they're going to change, and they've got to be able to latch on to like enough of it so they can say, "I'm doing Scrum." But what the consultants in the responsible phases need to do is NOT get people addicted to that, and that's where things go bad with "blame the consultant" is the consultant comes in and you have someone a class, and then people aren't successful and they blame the people, "You didn't do the process right." Well, if you're building the wrong thing and you build a little bit of it faster and you find out it's the wrong thing and you kill that project— that is success. But there's not a lot of rewards for that in the industry.

Brian Okken: Yeah, okay. You brought up testing. So, since this is something that I have kind of focused on a lot, I haven't heard you talk too much about where right now in the current model of how you're promoting, hopefully helping people to do things, learn about their product. What is the right role of testing then?

David Hussman: Yeah, I wanted to do a podcast, because I love the name, and Naresh Jain one of the guys in India has this conference he has done for years called Simple Design and Test, and it's a great model like everybody that attended the conference had to give a talk. And Naresh came out of like the XP space like I did. Your question is huge like what I think about testing today, in some ways, some aspects of it are as stupid as it's ever been. You know, there are still people that are like waiting to do all their testing at the end, there is far more people trying to move that stuff into more of a continuous realm. A lot of the stuff that's been done in the name of DevOps to me just seems like an evolution of what happened on every extreme programming project, except for the tools are better. Where people I think there are thinking more, testing is not as much about quality. I did a Matrix one time and I drew columns and rows and I put in the columns like what is the nature of the test, what are the tools you use, who is the audience and what are the purpose.

At the bottom I kind of stole language from J.B. Rainsberger and others and I kind of didn't call them unittests, I called them like microtests, or developer tests, and I think those tests, the purpose of them is they're like by the geeks for the geeks. They are design tools, they help tell the story of the code. And there are like the tests above those, I would maybe call them— we tragically still call them regression tests, or worse, integration tests. There is a name that needs to be refactored desperately.

Brian Okken: Yeah, it doesn't mean anything.

David Hussman: Exactly, they are continuous integration but they still have integration tests. Now, if they have a big system where they are integrating across subteams that's different, but I think of those tests like story tests, or product tests, or business tests. They tell the story of the product and people have like that kind of mindset I think are doing some really neat stuff because they're not saying, "Let's write more tests," or like one of the things that they did in Extreme Programming which was good when Extreme Programming came out was everything has to be done test driven, but that's sort of it, and it was like an unfunded mandate. In some cases it's not the right way to go, but if you think of test driven development and replace it with the words like test driven design, then you start I think having much higher order learning and that's what Kent wrote about in his book his Test Driven Book, he said, "When I want to learn a new programming language I write the X unit for that language." Which is really cool if you've ever seen how the story of J Unit, how they wrote J Unit, it's just an exploration of a language and there's really a nice dissertation, a little mini dissertation on patterns and things. Kent said, I've heard him say all sorts of things like, "When I'm stuck, I don't know what to do next, I just start writing tests." that's really an interesting statement because I'm sure he also goes to the Whiteboard sometimes but I think he does a lot of his design discovery with test automation. It makes a lot of sense, if you look at like when Bertrand— the guy that wrote Eiffel, I forgot his last name, Bertrand Meyer I think, Eiffel, when you enter a method, you had a pre and a post condition that was part of the language, and if either one of those failed, you've bopped out of the method and everything rolled back. And he put that into Eiffel, Eiffel didn't become popular because it was too complex.

But that's what I've always thought of, like there's an evolution that happens on a team when the change happens such that you call me over and instead of showing me your code, you show me your tests. Because then, I don't have to reverse engineer what your intent is I can see here's what you expect, here is the setup, here's the execution, here is the outcomes. And first of all, a lot of times people's ideas aren't good, so like fixing the code for a bad idea is a bad idea. And instead kind of looking at what they're trying to do, "Oh I get what you're trying to do," and then when you look at the code, you can zoom in fast to understand the intent. And that's easier in some languages than others, and I know I took your answer pretty far up, but I think that would sum it up by saying— I think people need to be thoughtful, intentional, mindful if you will about what tools they're using for what types of testing for what intent. And if you're trying to do design and it's like micro tests, and it's maybe some kind of X series testing, but if you're trying to learn about the product, it's not necessarily about more microtests it's about tests that are user read tests, those still are pretty lacking.

Brian Okken: Something is very confusing to me because that was my first take on, and so I came across test driven development when it was called test first programming. It was like we have to write all these, normally we in the waterfall model which is I won't get into how it's really unfortunate the Dr Royce has been blamed for all that. But we designed something, we write the software and then we write all the tests and then it takes a long time to get those test all passed, but wouldn't it be great if we had the tests first and then we could just write the code to make the tests pass. But in that model, the tests are not unit tests, the tests are testing the product.

And that's actually, that's where I approach test driven development and everything in there related to Agility is that I want to be able to make sure I'm testing the interaction with the user or with an API or something, and trying to figure out how to get that right. So it's bizarre to me that there are still people that say they're doing test driven development and then when they're done, they hand it off to the Q&A team to test the product. I think this is also, it must be different with different team sizes. So in a company that has Q&A departments, if you have the developers writing the end test then what does the Q&A department do? If you've got a smaller company with no Q&A, trying to get the developers to write both unit tests and end user tests, that's difficult. I'm sure. So what went wrong?

David Hussman: I think one time I was in a company and I kept getting hammered by this guy that I was using Q&A when I should have been using Q&C. So I just started running experiment and one week I would use the word Q&C all week. Next week I would use the word Q&A all week, just to see if anybody actually knew the difference between the two. And to answer your question, when it went wrong was when we started emulating quality control concepts from the manufacturing paradigm.

When I was a little kid you had a thing, something that was manufactured and used to say inspected by number 52\. Because that was Inspector number 52 at the end of the line, and in the manufacturing world, they had figured it out a long time ago, if you're producing 1000 units an hour, and inspector 52 inspects 2 out of that lot of a 1000 or 5 or some statistically significant set and they're wrong, you have a 1000 waste. So if you can get the inspector to do more continuous inspection, then you have less waste, you find the problems earlier and stop the line in Toyota and all that kind of stuff. Well, in software world, it was sad that we adapted a physical concept, a physical construct for our idea of quality. First we'll manufacture everything, then we'll throw it at the testing group and that's still pretty deep in a lot of companies' ethos. Instead of like what you were talking about, where my head space is, is like we should move that testing up sooner, we should do it more frequently, on smaller things, that's where it gets tough, is if you do it on 2 smaller things and you're trying to do product testing you miss the mark. But there are still some tests, the automated tests that need to be written that are not user facing, it has to do with some construct deep in our code that's complex. That's what I mean, I think automated unit tests tell the story of the code and if you're doing tests first in that space, then you're doing design with animation and to me, that's the most pleasing way to write tests. And these are great Kent Beck quote, someone asked Kent, "How do you know how many tests to write", and Kent said, "I just keep writing tests until I am not scared anymore."

Brian Okken: Oh that's great.

David Hussman: That's a great answer, isn't it? Because he didn't say 65% coverage and it's such a great answer because it's contextually significant. Maybe I'm working on something that's Greenfield, I don't even know if it's going to be successful. The idea of full test coverage can actually be a very poor investment, but it has to be good enough. And so, if you apply Kent's standard, I'm not scared anymore because I've written the tests that I think are going to be either user advocacy tests or the tests are going to tell the story of the code where there is a need to tell the story with automation. I love our conversation right now. I fear a little bit, like with the— I was going to say the demise but let's just say the waning of extreme programming that a lot of that stuff got lost. I do see people in the DevOps community sort of rediscovering a lot of what XP was in 2000 which is wonderful, I don't really care where people learn it, as long as they adapt a responsible, I think Kent once called it like responsive or responsible engineering, I thought that was a nice term.

Brian Okken: Yeah, actually you guys take that and have a training course around that don't you?

David Hussman: Yeah.

Brian Okken: A lot of it is just people trying to get shit done, get the product and like you said so you're not scared anymore, so you can go off on the weekend and not worry about whether or not you're going to get a call in the middle of the night. I like the idea of the test until you are not scared anymore, it covers a lot of stuff.

David Hussman: I'll tell you, Kent and Ward, those guys are like wizards and they are like little kitty wizards, every time I'm with one or the two of them I walk away with two little things like that "I think my life is now better, I'm a better programmer," because I listened to Kent talk for 30 minutes.

Brian Okken: Yeah, one of my disagreements with a lot of this group of people though is an idea that you should teach people the right way to do things just at a micro level and assume that they're going to become an expert and grow and know when to break the model. Like for instance, we brought up Scrum, I read about Scrum and one of the things I loved about the Scrum model was this notion that you change the process to work for your team on a regular basis, and yet we have a lot of people saying, "Oh, you're not doing it right, because you're doing it differently than my team." Of course, if you're doing it right two teams are doing it differently.

David Hussman: And the only measure of right is, I heard someone once say, "If your product sucks, so does your process." What bugs me is, if you want me to get dark a little bit, most large companies I am associated with now have some kind of Agile council or Agile coaching committee or Agile adoption crew or blah, blah, blah, they're transformation to whatever metaphor they've chosen. And the worst of them are walking around, doing exactly what I've seen PMO's do for years and years— make everybody march the same way therefore, we'll have more marchers and we'll win more wars or whatever, I don't even know what their analogy is but they fail to go and look at a team and say, "Look, these people  practice in civil disobedience, and they've found a better way to do it and if they're more successful than our other teams who are 'doing scrum' instead of running it down, we should figure out what they're doing, because it might be something that's unique to our company that isn't in the Scrum book because the Scrum book was not written about our company." And that kills especially when really thoughtful, passionate people are crushed by the Scrum hammer, it's not really Scrum's fault, it's just anyone that turns out like you said, where the methodology becomes more important than the impact that it produces.

Brian Okken: Yeah, and that's where the— we haven't brought this up yet, but the Dude's Law is perfect thing, you're a brilliant person for coming up with that. So Dude's Law is, if I'm getting this right, the V=W/H or Value=Why/ How. And if you do the math, your process or your mechanics, if you spend too much time on that without spending more time on figuring out why you're doing what you're doing, than you're going to lose. I'm probably getting this wrong, so do you have an elevator pitch for the way you do it?

David Hussman: You're doing it perfect, I mean the nature of, if you imagine you had an equation that says V=W/H. The nature of learning is how. I used to teach guitar lessons and when people can't even strum a chord, they've got to just focus on the mechanics how and you teach them how to play a few chords. But the reason they came to guitar lessons in the first place is probably to play a song, that's the why. So in music it's very different, because it's so immersive that as soon as you can make it through a song, you go and play the song, you damage everyone in your family that has to listen to you hack through some horrible tune that you can barely play, but you've made it through a song, and you're not like obsessed with G, C, D, A minor and F anymore, you've learned how to play the chords.

The software world is not as obvious, so people get so obsessed with "How are we doing the process" that they forget why they're doing the process. I see it all the time at companies were their Agile success is scorecarded based on the number of practices they're doing, instead of the impact those practices are having. And if you take very concretely, like a daily standup. The daily standups I was in, we just went around and talked to each other and sometimes we didn't have anything to say and we just said "pass" that was a difference between like XP and Scrum, in Scrum they implemented "the three questions" and people end up kind of saying, "Yesterday I was in meetings all day, today I am in meetings all day, no blockers," I am like, "Thanks for sharing, I am glad I've spent my morning listening to six people say that." And when I'm coaching, I might call one of those people out gently and say, "Well what were those meetings about?" And then someone might start saying, "Well you know, we're working on these stories and we're having a really hard time with it," and someone else might say, "Oh, I once worked on those stories I could help you, hey, let's get together right after the stand-up," and that's the idea of that meaning, is make connections, surface issues and do something about it. But when people follow the ritual, it's all the emphasis on how, and I just sort of feel like when I was teaching guitar I wanted my students to eventually never come back because they were good musicians, not because they became bored with practice, but because they became players.

Brian Okken: I really like this music analogy because there's more to it I think, and we can take this a lot farther. One of the things is in order to be able to get master a lot of the technique, you have to care about it. And in order to care about it, you've got this feedback loop of "I've made it, I performed a complete song or a part of a song," and it feels good to have other people say, "Well that was really good, awesome." And then you can build up from there and you want to get better, you want to learn different techniques.

And it's something that actually I'm learning now as I'm growing as a team lead and understanding that people are not experts at everything, even if they're experts at something, to use this sort of a feedback loop even in small scale. So if I ask somebody to do something new that they haven't done before, even if they're awesome at something else, I've got to be able to give them something small enough that they can get the whole way through even if they're not quite doing it right, and then have that success and then they can both of us together or the team as a whole can improve the process, but making that whole feedback loop or performance shorter and more frequent. I think that's also part of why some of the. continuous stuff works that we don't really talk about.

David Hussman: That was really interesting. We sort of went from continuous integration early on in XP and my experience was I went from continuous integration, I went to, "Hey, this is good, let's start doing like continues deployment," we used to practice this thing called new 30:19 which means every time the build ran we would wipe up the environment to the best of our abilities, new kit and repave it so that the environment is deterministic. And we started taking more and more control but we're still in it too early 2000's stuck with physicality, we couldn't just drop VM's and it was hard to just wipe out, the only place I ever did it was in this project for the government where we were using early prototype blade servers and we would just wipe a whole blade server and blow down a whole new instance of Linux side of the thing.

And we started using that language continuous, it was continuous integration, continuous deployment, and then our goal was continuous readiness and I love that language because it's certainly what the DevOps world is doing. Again, it's just there's way more flexibility. But probably, if we were to put the word in there it would be a continuous performance or something, like gaming groups that I have worked with, the fun gaming groups, it's pretty common once a week at a minimum where people just shut down and everybody plays the game. And it's like playing a song or something, everybody experiences what it's like, that doesn't happen in banks, the softer don't say, "Hey, let's play banking for two hours," they have no idea what it's like to be some branch manager that's trying to help someone set up some account somewhere and the branch manager is apologizing because the person has to sign six different times, when they should only sign once because some back end system is now correlated to another one or something like that.

I agree with you, there's so many parallels but one of the strongest parallels is that very few people can look at a music score and hear it and that's what a really great composer can do, they're supposed to be able to actually look at the score and pretty much hear the orchestra. There is even fewer of us and I'm not one of them, that can look at a pile of code and say, "Man, I bet that's going to really feel great when it runs," and the tests help us say, "I think it's going to run," and we're stumbling towards more analytics that are more automated with more automated tests that try to express, "Yep, it's a good experience but we're not very good at that yet." That's probably a better answer if your testing question is,I just feel like we're still doing a lot of times with the tools we have to do automated product learning with test automation, it's tools like what is your favorite tool in that space, what is your favorite tool for product testing automation?

Brian Okken: Right now it's Pytest.

David Hussman: But you just use it at whatever level, right?

Brian Okken: Yeah, I just use it at every level. My favorite way to interact with any software that we're using is through, now I can't remember if it was Kent or somebody else that came up with it— no, I know it was somebody else, but the Subcutaneous model, just the idea that even if you don't have— some products are designed where the user interface sits on top of a an API layer and if you don't have that, if you've got like a web interface, well there's still, now we're moving towards Rest interfaces, so it's a programmatic layer that you can do everything you can with the user interface just it's easier to write tests for and it's easier to automate things. I also grew up in like the Unix world where it's this idea of I don't know how people are going to use this tool, but I'm a make make it so that people can plug things together, so make one tool, make it do something good and I don't know how it's going to be used, but I'm going to try to make it flexible.

And for a long time, I was the weirdo in the team that when we would pick a new product, I would say, "Well, where's the command line interface?" They're like, "Oh no, it's a web interface, we don't need a command line interface." I'm like, "Well, I'm going to want to hook it up to our build server or something, and so it better have a command line interface." But as far as user interfaces are concerned, I've been fortunate enough to work, like Kent and others at Tektronix I work on instruments a lot, so we are guaranteed to have all of our functionality is programatically accessible, the user interface for people is for people in fingers is not necessarily the primary interface.

David Hussman: You work at Techtronix right now?

Brian Okken: No, I started Agilen, or HP and Agilen and now I work for Rohde and Schwarz which is a German company than in a similar space as Techtronix.

David Hussman: It's like that's really neat. I've cut my teeth working on hardware, software, firmware combinations and we were always trying to figure out ways to write automated tests, especially when there were medical devices because you have to do the testing. And I've always joked for years and years, the best way to get automation is make an engineer do things manually and then you get automation, it just happens. And, when I learned test driven to me, it replaced the crazy set of post-its that I had at my desk, or all the crap I was trying to do with like a main method in C++. And in other languages it was like, "Holy smokes look at all this power I have," and I was blown away by the number of programmers I met from 2000 to 2003 that would just say things to me like, "I don't need to write tests, I write good code." These were dudes whose code didn't even compile. And you go sit with them and you watch them work, and I think, "Boy, if you could just get past your ego,"

One of those things that's brilliant about test driven or using tests as design tools is all the code you don't write, that potentially has bugs. One of my favorite jokes I heard 10 years ago was, "The only code with no bugs it's no code." People don't take into account that if you don't write it you know have to fix it, and that's fundamental in the whole programming space and test driven, when it's a design tool— that was of funny joke early on, Kent said, "I taught my daughter how to pair program with me, she sat next to me and every three minutes she said 'Dad, do you have a test for that?' "

Because when you're forced to justify your designs with automated tests, you do less stupid stuff, because it's a real time design. I always thought pair programming when it's not done dogmatically, which is all about the how, when it's done based on the why, is like real time design with someone else, and that's why I think saying you have to do it all with time feels weird and dogmatic, but my programming history especially in the mid 1990's when I was working on multiple versions of C++ and multiple operating systems, is sitting with someone else is exactly what we did anytime there was a hard problem. We didn't use tests as design tools, if we would have, we would have moved even faster but that's what you always did. Martin Fowler once said, "If the hardest part of programming was typing, pair programming would be a bad idea." But it's not the hardest part of programmer is the thinking and the design work.

Brian Okken: I like the idea of using pair programming when you're stuck on something or when you need to design something. I admit that I've been very reluctant to even embrace pair programming at all because it's sort of a joke, but sort of not really that I got into programming not because I really loved being around people. Actually, you've brought up Martin Fowler, which I'm glad you did, because he's the person to give credit for a subcutaneous model. This has been a really good talk and we kind of meandered around. What are you mostly thinking about now? When I first tried to get you on, you were promoting like story tests.

David Hussman: I've been super disillusioned by Agile as an industry, that is kind of uninteresting probably any movement. I'm in enamoured with the stuff that's going on in the DevOps space, because I think they're rediscovering collaboration and putting it forward again, what I think is a strong component of extreme programming. I think they're doing a lot to sort of like solve the problems that are solvable, so we should be able to pipeline stuff and deploy it and not worry. We should have enough confidence. On the other end of the spectrum, I'm really intrigued by a lot of the work that I would say is happening outside of the code.

One of the areas where extreme programming did not evolve well, and it's not a mistake, it's just the people started to let it go, is that assuming that the stories you wrote are the right stories across time and space is ignorant, it's naive maybe is a nicer way to put it. But I think we need to start sort of a continuous discovery which feeds sort of a continuous delivery and most of the DevOps stuff is kind of down in the continuous delivery space. But what I always saw, if you take a very simple example, you have a team of 10 to 12, and some people are very close to the code and some people are closer to the market, and some teams they call a person that sits with everybody a product owner, even though they don't really know anything about the market which is a problem in Scrum.

Some people there are thinking, "But hey, where should we go?" The discovery spot. And some people are thinking about, "How do we get there?" the delivery side of it. I think that if more teams looked at like their bandwidth just arbitrarily say for iteration and I don't get too wound up about iterations, and you said, "For the next N days should we spend more of our time in discovery or more of our time in delivery?" Then we'll really have the next evolution where some of the programmers shouldn't be writing more code about things that are not really validated ideas, that's a waste of time and you're building out an inventory of code, more code more problems, more complexity. It's sort of a negative way to look at it, but there's always a handful of developers, maybe a couple, that are really passionate, they want to talk to people, they want to engage with the customer.

So why is it bad for that person to maybe spend more of their time running small experiments outside of the delivery space so that we could be a little bit more sure that that is the right idea before we just line up the code and deploy it into production. And we don't do that because deep, deep in the ethos of most people wielding code especially places where they say the word "IT" is more programmers writing more code means more progress, it's just such a mess, it's a deep mess. Validating that what you're doing is right is what feeds more progress and then more learning and potentially more value, but you have to figure out whether your next investment is to learn outside of the code or inside the code. And that's where like XP I think what we did that was good is we came up with this idea of refactoring the code and keeping the system healthy. But there are still too many people that are sprinting away, getting stuff done in a sprint, and the safe world is probably even worse because they're doing it with multiple teams and all they've done is like synchronized and optimized potentially building the wrong thing faster. That's why I named the talk "How to build the wrong thing faster" because I wanted to plant the seed with people to say just because you've got stuff done doesn't mean it's right, that's where that metaphor that you use I think is powerful, but dangerously powerful, it gets stuff done and that's good if it's the right stuff, if it's not the right stuff you're better off not doing anything because you're not producing wrong code.

Brian Okken: I try to remind people that Agility has a meaning outside of software also. And part of that is being able to change direction and to not get too far into some code without being willing to throw it away and start over. And for a long time that's how I taught new developers on a team, I said, "I'm going to ask you to do something and then we're going to throw it away and you're going to do it again." Just so that they experience that feeling that you may have spent like three weeks building something, but you can do it again in like two days, because the person at the end is way more qualified to do that code than the person that started. A big resistant I have for a lot of the unit tests is having that be extra resistance to change, when people aren't willing to change design because it would be too difficult to change the tests. That's a really big red flag that you've got tests at their own level, if you're not willing to change them.

David Hussman: Or you just waited too long to make the change and now it's too big to fail stuff.

Brian Okken: You reminded me of like doing these experiments if we're doing the right product. The most fun I've had is when we get to work very early in a technology where I'm working with another company so two companies are working together and they don't really know what the answer is and you've got engineers on both sides saying, "Well, like let's put this measurement in place and see if that helps us with the product we're trying to make," and then we'll say something like, "We can give you a like L for release like in two weeks but it may have huge bugs and it might even crash." And they're like, "We don't care right now, we just want to see if we're going in the right direction." And yeah, I love that, I think more and more of our software and even hardware now can be done with "Let's try doing something and see if we're going in the right direction first."

David Hussman: So many people that are saying, "We're doing Agile have very much a constructionist ideology, we're going to get stuff done," it's like that's good if what you're doing is very known. You get it done and you're successful. But if you paint a continuum which I probably did in that talk, where on one end is construction and on the other is experimentation, the closer you are to experimentation, the less it matters how much you've got done, what matters is how much you learned. And it's interesting to listen to the talk because I grew up like you did, working on things that weren't solved or that were new and the nature of learning is not measuring units completed. I was talking to a friend in aerospace industry and she was lamenting the fact that the Agile people were coming into her R&D team and they were trying to treat it like the IT side of the company and she's like, "I've got five brilliant PhDs and they're not going to pair program and I'm not going to let them because it's a stupid idea." And some of the problems we're working on can be done in two hours or two days, and I was explaining to her like the problem is that people are measuring progress instead of measuring learning or eliminating uncertainty that startup people put out, that was nice language, it was neat to see can't gravitate towards that lean startup crowd. I thought that was interesting.

Brian Okken: Yeah, the lean is a very good thing and that's where I think those are good lessons there too. This is getting a little long in the tooth, but I really appreciate you coming on and thanks a ton for taking the time out of your day and talking with me and I've really enjoyed it and learned a lot.

David Hussman: My pleasure, man.

Brian Okken: Thank you for listening. The show notes with links to items we talked about are at testandcode.com. If you like this show, please spread the word. Tell a friend or colleague about the show or email them a link, rate it on iTunes or Overcast or whatever you're listening to this on. Let me know if there are other topics you'd like to have covered. Reach me on Twitter at @BrianOkken or the show at @testpodcast or at @testandcode. Thanks a lot!