Podcast: Ron Jeffries and Chet Hendrickson
Hiya! This month on the Cucumber Podcast we speak to Ron Jeffries and Chet Hendrickson. They are probably best known for their association with the Agile Manifesto - Ron, one of the authors, Chet the first signatory. They've both done some other stuff too. This is a wide-ranging conversation hosted by Matt Wynne with fellow Cucumber people Sal Freudenberg, Steve Tooke and Aslak Hellesøy.
Transcript
Matt: Welcome to the Cucumber Podcast! My name is Matt Wynne and one of the immense privileges of running this podcast is that every now and again, I get to speak to some people who are my heroes. Unfortunately, this week though, we’ve only got some guys called Ron Jeffries and Chet Hendrickson. Sal, why have we invited these two on? Who are they?
Sal: I’m sure everybody knows this already, but Ron’s one of the creators of the Agile Manifesto. Chet, I believe, is the first signatory ever of the Agile Manifesto. Ron and Chet are still very much practitioners and active parts of the community. Also, I really, really appreciated the fact that they’re champions for diversity and inclusion, which is a massive passion of myself. Most of all, whenever I speak to them or whenever I listen to them or whenever I read anything that they’ve written down, I learn something new, so I’m really curious to find out what I can learn from them today.
Matt: So, where are we going to start? There are so many things we could talk to you two about. Obviously, Agile is something that you guys were responsible for kicking off and it’s been a long time now. Do you want to just give us a quick look back on that and what you think has been good since those heady, early days and what’s not been so good? What are your reflections on all those years?
Ron: It seemed to me that at that time we did this, I had great hopes that the world was going to become transformed – the relationship between software developers and the people who use them to build products or use them to build internal things or whatever – that that relationship is going to be much improved, that the productivity of programming was going to increase, that the happiness of both programmers and people on the business side would be increased and that probably, as a result, world peace would come about. As it happens, none of that has really happened.
Chet: And I think it’s all our fault! I think where we expected the world to be nearly 20 years on is not where we’ve ended up, which is not really surprising because that’s never how the real world works. We are seeing some things that bother us. In fact, we just spoke about that yesterday at the Deliver Agile Conference where the title of the talk was… What was the title of the talk?
Ron: “Developers should abandon Agile.”
Chet: Developers should abandon Agile. I then added, “Before it abandons you.” In fact, we kind of think it’s too late. We believe that Agile has abandoned developers and it has turned into a thing that is owned by management, by people who don’t see developers as a first-class member of the organization, so much so that we often see development being done in places that are thousands of miles away from where the people the business cares about are. We treat them as interchangeable components, and we get what we get because of that. We believe that it’s time for developers to take back Agile.
Aslak: What you’re describing sounds very similar to what the situation was like before Agile was invented.
Chet: Yes, and that makes us sad. We see a little bit of change around the world, but I don’t know that it was 100% positive. Surely not 100%. I’m not sure if the sign of the change was positive or negative. When I first started doing software back when I had hair, I’d get something to work on. I was given something to do and it might take weeks or maybe even a month or so to build something and along the way, I might have to tell somebody how things are going every week or so, but now, we have Scrum and every day, I have to stand up at 9:30 and confess everything I did over the past 24 hours and everything I predict I am going to do over the next 24 hours. I don’t think that’s what that meeting is about really. I don’t think that’s what we had in mind, so we believe that no matter whose fault this is – and I believe that no matter whose fault this is, that the solution has to come from us, developers, because we’re not doing the things that XP is built upon, which is, “Say what you’re going to do and then, actually do it.”
Ron: When we started our chat with the gang yesterday, we showed two little charts that we think represent what goes on with Agile. One of them was what we think the impact of Agile is on the business and we think that even if you don’t do it very well, the business makes a little bit of progress. They start out a little happier because at least they begin to see what’s happening, they interact with the developers more and we think that in general, most people will undertake Scrum or some other allegedly Agile method, the business side will be happy and we think that when you start out doing Agile as a developer, your life gets worse the way that Chet just described. You get less time to do your work and more time to have people putting pressure on you. As Chet says, we think that the reaction to that needs to be for the developers to learn how to take it on themselves, to learn how to do development in such a way that they can survive the situation. There’s not much support for that in the business community. Nobody wants to send all their developers to actually learn how to do Test-Driven Development (TDD), refactoring and so on. What we think has to happen is that we’ve got to find ways for the development community to almost literally sever itself from the current Agile thinking and start thinking about what we call “Agile software development” which is not what Scrum and the other methods are about at all.
Chet: Three-four weeks ago was the Scrum gathering in Minneapolis here in the US and there were 1300 Scrum masters. We just had the Deliver Agile Conference in Austin and we had 300 developers. If you know anything about a Scrum team, you’re supposed to have one Scrum Master and six to nine developers. I don’t think what we’ve just said – 1300:300 – represents that ratio in any reasonable way. There’s been 600,000 or so people who have gone through certified Scrum Master training, a couple of hundred thousand through Product Owner training and the number of folks who have gone through the Scrum Alliance’s developer training would fit on the back seat of a large American car.
Ron: There are actually 42 certified Scrum masters for every single certified Scrum developer.
Matt: I don’t know much about the certified Scrum developer, but once somebody’s come through that, are they pretty much addicted to TDD? Are they going to be doing software development the way we would like to see it done?
Chet: Like all of these things, they are introduction to these things. In a three or five-day developer course, we can show you what these things are, we can show you what happens when you do them and teach you a few things about how it’s supposed to work in the same sort of way that in a two-day CSM course, we can teach you two days’ worth of stuff about Scrum. All of those things are learner’s permits, allow us to get on the road and learn how to do the rest of the stuff. Sometimes, you should maybe have a parent in the car with you.
Sal: I have a question. You’ve used two different words that to me mean something quite different. One of them is “abandon” Agile and the other is “reclaim”. Have we got to a moment where it’s actually, “Abandon everything to do with Agile, start from scratch,” or do you think reclaiming the original essence of the practices is actually more useful than just abandoning and completely severing?
Ron: I believe that reclaim is out of the question, impossible. The popularity of Agile in the business world, the forces of the companies that are doing the best to do real Agile – I think probably the Scrum Alliance try to do something they consider real Agile – and the ones who are not trying to do something that is real Agile which might be people who sell products like JIRA and Rally… I believe that they own that space. We need to build an approach which in fact reclaims the practices and values that you talk about, that takes us back to understanding what those are and brings us forward to the understanding that we have today because as you guys know, there are products and things out there that were not there then and there are ways of working now that are far better than what we had then. People know now how to ship real live customer code multiple times a day. What really needs to happen – and of course, we’re saying this emphatically for a fact – is the developers need to operate in a mode, saying, “We are going to be placed into one of these ‘Agile environments’ and we need, as developers, to understand how to develop software in such a way that we will thrive in that environment.”I don’t really want developers and business people to be in conflict, but I think the developers have to take back the responsibility to know these things, to know the Agile practices as the developers’ side of Agile has promulgated, but I would not like to see developers saying that they’re part of Scrum or that they’re part of SAFe or that they’re part of anything. I think software developers have to go back to being part of software development. I was there when the manifesto was written and that’s kind of a harsh way to put it, but I really do not see a trend that’s making the world better for software developers and as Kent Beck once said, “You got into the business to make the world better for software development.”
Tooky: I’m really reminded about a conversation I had with Woody Zuill. He was telling me about “The Systems Bible” by John Gall and he was talking about steady state systems. Steady state systems get disrupted. You give them a big push and unless you keep pushing, unless you keep disrupting them, they kind of swing back to where they were. This conversation that we’re having sounds to me like XP and Agile and Scrum and all of that was the disruption, the big push to the steady state of software development, but maybe we haven’t kept pushing and we’ve come back to that steady state of where it was before.
Chet: I think that’s a good way of looking at it. Our power to push is rather limited than the power of the other people to cause it to go back to base course. It overwhelms the power of the software developers because that’s just the nature of the universe that we work in. We might have to find a way to do the things that we know are right without those folks noticing us. Years ago, someone once asked one of our people – I don’t think it was Ron or I, but they asked somebody – “How do we convince our bosses to let us do pair programming or one of those things?” They said, “Well, just do it because they don’t know what you’re doing now anyway. Therefore, you should have the courage to go off and do the right thing because your boss really doesn’t know how you do your job now, particularly if they’re some number of time zones away from you. They certainly don’t know how you’re doing your job.” What we have to do is find ways of telling folks and encouraging people to spend time to learn how to do this work in such a way that you’re not inviting those folks to come in and manage you. We believe the basic ideas in XP allowed us to do that because it allows us to say, “This is what we’re going to do,” and then, do it at a very high level of quality and a very repeatable sort of way. If you’re not doing that, then you’re inviting someone to come along and manage you in some way, to pull you up by the roots and find out what’s going on. Well, this is a really upbeat talk isn’t it?!
Ron: I won’t argue that this is fantastically upbeat because what’s it about is software developers owning the responsibility to do their job well and to do it in such a way that no matter what kinds of management you get, you will be able to thrive. If you get horrible, draconian management, you can still live as well as you possibly can by producing quality software on regular basis that does what you said it would do and if, by some strange chance, that does help these people understand that it’s time to be more responsive and to pay more attention to what should we do next and set up the big plan, it will be even better. If you accidentally find yourself in an organization that was doing Agile with quotes around it in the way that the “Agile” people say you should do it, it would be fantastically good. I don’t think it’s a negative notion to say, “Break away from the stuff that is Agile today. Do the job really, really well and maybe Agile will come around and join you, and if it doesn’t, you’ll still be doing your job really, really well.”
Aslak: I think there are quite a lot of organizations out there where management manage the developers, the developers feel like they work in some sort of tyranny where they don’t have freedom to do Agile properly or XP, but I also think there are probably many organizations where the developers do have a lot of freedom, but they don’t want to do XP because or Agile. They don’t want pair-programming, they don’t want to do TDD and they might even have managers that tell them that they should do it, but my impression is that young developers and people in their 20s perceive these things as old fashioned, as It doesn’t work.
Chet: I don’t think that Ron and I really care if these folks are doing these exact things or not. If they have found a better way to achieve the things that we achieved with those 13 practices 27 years ago, that would be wonderful. If they can produce day after day, week after week, month after month software that does exactly what it’s supposed to do on time, on budget, with a minuscule amount of defects in it using different techniques, I would like to go there and have them teach me how to do that. If you’re producing stuff that doesn’t work, that takes twice as long to build as you said it was going to, that the feature that you add today costs way more than if you had added it last week, then those folks have things they need to be learning.
Sal: That kind of leads me to a question. Are there things that you see that give you hope in this? What are the kind of things that you’re seeing and you’re thinking, “Oh, actually, that does seem like it’s taking what was originally there, moving it forward, changing things and the software development practices”?
Ron: I think this is actually a very hopeful message. The message is, “As developers, we will thrive if we do our jobs well.” To the earlier question, nobody in management should be telling programmers to do TDD. Nobody in management should be telling programmers to do pair-programming. What you’re supposed to do – it says right there in the Manifesto – is create self-organizing teams and let them figure out how to do the work. They need help, they need education and so on. Our experience with developers with not just a couple of years of experience, but even five-ten years of experience is many of them don’t even write very good code. I probably thought I was writing really good code 40 years ago or whenever it was that I was only ten years into this, but I wasn’t and I learnt at the beginning of this Agile era, when I had already been programming for 35 years, that I did not write really good code because I’ve met some people who knew how to write some really, really, really good code and I began to learn from that and now, I would say I probably write pretty good code. I think this is a call for developers to look to their own community and to look toward their own future to do good stuff. If they can really do that – if they can write reliable code on the clock and not to say, “You get to tell me when I’ll be done…” If I say, “I can do this in two days,” then I can do it in two days and when I give it to you, it works, and when I give it to you, it’s integrated, and when I give it to you, it’s fully tested, and when I change it, I don’t break it, if I can do that, then I can thrive anywhere. I think that’s brilliant and I think it’s actually a lot better than imagining that what’s going to make my life better is a product owner and a Scrum master in the room talking to me.
Matt: Just don’t call it “software craftsmanship” because we don’t need that for a brand for this. I get what you’re talking about. I like this as a rallying cry.
Ron: I am having a little trouble with that brand. I think that’s coming about for more than one reason. One is that apparently, the word “man” in “craftsmanship” means something different to some people than others. I think that just has to be accomodated, it’s unfortunate that people hear discrimination in a word that’s hundreds and hundreds of years old, but it represents systemic discrimination for hundreds and hundreds of years. I think the word is bad, not because it’s a bad word, but because half the population in the world doesn’t hear it right.
Chet: I don’t believe I’d say that half the population doesn’t hear it right. It depends on which half you’re talking about. Maybe we’re the half that doesn’t hear it right.
Ron: Probably there is no “right” in this. The point is that the word doesn’t work for everyone and the word’s bad therefore. I think that in addition, there are problems within that community.
Matt: There’s something interesting about this though. Sarah Mei wrote a Tweet the other day about privilege and there were some interesting thoughts in that thread. I know you chipped in, Ron, a little bit as well. One of the things that strikes me when I hear both of you talking about developers standing up for themselves and holding their ground about what quality means and what it means to do a good job is that… I have an experience from a lot earlier in my career where I actually got fired for doing TDD because I was being too slow. It was quite a blow at the time, but I was fortunate enough that I was able to find another job and carry on and kind of stick to my principles and find an environment where that kind of thing was valued, rather than actually an environment that wasn’t valuing that kind of thing. I think it’s easy to make an assumption for those of us who are belligerent characters that will go into organizations and try and change them that everybody is prepared to take those kinds of risks and stand up for themselves in that way. Actually, a lot of the developers I meet maybe would be quite afraid to set those boundaries in such a courageous way. What do you guys think about that?
Chet: Ron and I certainly have a great deal of privilege that we’re able to say what we want to say and can be relatively inured against any feedback. We’re both old. Ron has essentially decided that no one has enough money that would cause him to leave his house and go some place and work. I tried to act as if that is the case for me, but that doesn’t really matter. We should all find ways to be courageous enough to do that. I often tell the story of my younger sister, Beth, who was a software developer for an American big-box store, Home Depot. I don’t know if you have Home Depot over where you are.
Matt: Yeah, it’s B&Q in the UK. I don’t know what it stands for.
Chet: She was on a team that ran systems that maintained the store’s catalogue. There’s a computer in every store and it has the price of everything on it. They updated those prices every night when the store was closed, electronically. She had just had her second daughter, Bridget, who is graduating from college this weekend, and she said, because of the way their software ran… When it ran, they had a pager. They rotated through the group and every Friday, they swapped who had the pager and it was Beth’s turn to have the pager and she said, “I’m not going to take the pager home anymore because it goes off just after I get Bridget to sleep and I’m almost asleep and it goes off and it’s ruining my life.” She said, “I don’t care if I come back on Monday, but I’m not taking the pager home anymore.” She was in her 20s, two children, a husband who had a good job as well, but she didn’t mind not coming back on Monday, because she knew if she needed a job, she could find one. Maybe we should always act that way. Life’s too short to live that way. We didn’t go to school all these years to work that way. I’ve tried to live as if I don’t care whether I have to come back on Monday or not, but there are some pagers I’m not going to take home.
Ron: I would say that not everybody is able to feel that way; not everybody has the freedom to do that. Some of us live hand to mouth and really couldn’t afford to lose their job for two weeks. We are certainly not demanding anything, but we aren’t demanding that all developers should go and be in people’s face about how they develop software. On the other hand, it is also the case – and I wanted to reflect on this – GeePaw Hill has a series of video things that he’s been putting out lately and one of the most excellent ones is the one in which he says – and I have to agree with him – that microtesting, as he calls it, or test-driven development is the fastest way he knows to develop software that works. It is an odd experience to work with TDD because it feels like going very slowly, but when one is doing it well, one actually is producing software faster than one who wrote it and then debugged it for the rest of the month. Of course, if it doesn’t have to work, you can develop it without TDD pretty readily.
Chet: I always like to say that if it doesn’t have to work, I’m done now, which may be what Matt should’ve told them.
Matt: The hard part was learning TDD. So, honestly, that job that I was in where I got in trouble, I was still learning how to do TDD and it was slower for me to write tests and figure out how to write tests, especially for that technology stack and write the code than it was actually for me to just do it the way I already knew, which was to write the code, keep pressing F5 in my browser and testing it that way. It was slower because I was learning how to do TDD while I was doing TDD and I think this is the place where we need to start to bridge the relationship with the business again because the business need to recognize that they’re going to have to make that investment in their people. They are going to have to buy their developers that space to learn a new skill so they can level up.
Aslak: I don’t think I’ve ever met anyone who taught themselves TDD without having somebody teach them. I tried for a couple of years. I moved to another country because I wanted to learn TDD so bad.
Ron: Because TDD won’t grow where you typically live?
Matt : It’s not allowed in Norway!
Aslak: It was in 2002 in Norway. Nobody had heard of it!
Ron: I wish that all companies would invest in their programmers and I observe that many do not, particularly large companies. I also think that many of us – probably all of us here – have been privileged enough to get some support from companies and to be free enough to be able to learn things and have enough money somehow to be able to study things and buy books. Not everybody has that level of privilege. I believe that the community – and I think I mostly mean the development community – needs to find ways to bring ourselves up, to bring up our brothers and sisters, even the ones who can’t take much time or spend much money to do things. There are some fantastic resources on the web now for test-driven development. What there are not are interactive ways where you could get on the internet on one of these forums or chat groups and actually pair with someone to do it, but I think we have to find ways to do that because of this thing that I call “dark Agile” or “dark Scrum”. Some big component of the Agile installations is really oppressing the programmers. We have visited a number of what I call “the insurance minds of Ohio” which have huge buildings full of programmers who never get to see a window. I believe some of them are not even allowed to have windows in their automobiles and they work literally in the bowels of these corporations in tiny rooms packed with programmers and probably animals of some kind – I don’t know – and they don’t get a lot of support. I think we have to find ways to do that. I’m arguing – and I will continue to argue – that organizations that are making a lot of money selling business Agile should be concerned about this and that they should be investing some of the money they make back into making sure the developers are successful because business Agile is not going to work if it doesn’t work. If people had decent expectations, a lot of them would say, “This isn’t working,” and they might figure out that the programmers don’t know how to do it. I think that we have to do this somehow as a community of developers and people who care about developers because I’m of the opinion that we can’t trust the corporation to do it for their own reasons. I’m not saying they’re evil; I’m just saying they won’t do it.
Aslak: If doing it is so beneficial, isn’t that just going to resolve itself? In order to be successful, you have to do it, and if you don’t do it, you won’t be successful.
Sal: I think sometimes because of programmers being oppressed, people do feel like they have to ask permission, they feel like they do have to say, “Can I pair?” or, “Is it okay to use these new techniques?” I remember having someone ask a question, “How do I persuade my product owner to allow me to spend time refactoring?” The answer was, “It’s not really their business how you do the craft the programming, the job of programming. That’s the due diligence of the development team.” So, when they say, “Here’s a piece of work,” then when you think about that piece of work, you think about it in its entirety, including refactoring, including TDD, including anything that you know is going to be the best way of doing it, but somehow, those two things have got a bit embroiled and I think programmers more feel like they have to ask permission now which is kind of odd.
Chet: I think you’re right. It seems odd that we ask permission. We believe we have to have permission to do good work. I believe that on the first day of a new greenfield project, the code base is perfect. It does absolutely nothing and it does it in zero lines of code; there are no defects. It’s beautiful! Perfect! Every time we add a feature, our job is to get it back as close as we can to that level of perfection so that whatever we do next would be as if it was the first day we ever did. Therefore, if we didn’t have any of these constraints, imagine working that way – that everything that I did was like the first line of code I wrote in this file, in this project. That’s where we want to get to. That’s what the craft is – learning how to get back to that point before I say, “Okay, I’m done with this.”
Matt: One of the things I think is hard for a developer is that very often, the mess that you make and that takes you away from that place of perfection where you were on the first day is not obvious to you until maybe some time after you’ve made it. You make some decisions and you live with them for a while and then, you start to realize, “I really regret that decision. I would like to rework that code,” and you’re responsible for that decision or you, as a team, are responsible for it and there’s something difficult about having courage – and maybe you feel like you have to ask for permission – to be able to say, “That stuff I did a month ago… I’m kind of embarrassed about it now and I wish I hadn’t done it that way and I would like some time to change it around to this other thing which I think would be better.” That actually probably does need to be a little bit of a give-and-take decision with someone who can help prioritize because it’s, “Should we spend a week reworking that stuff I wish we hadn’t done and do it differently or should we carry on living with the annoyance of it, slowing us down slightly for a little while longer?” I think those can be healthy conversations to have.
Ron: I would want to say that that is the wrong question. It is the case that often, a week or a month later, we realize that this particular code isn’t ideal and that it needs to be changed and the question isn’t, “Should I change it and spend a bunch of time changing it or should I live with it?” The question is, “How can I change this code as part of the work of delivering new features?” Once the campground is dirty, the boy scouts don’t always go in and spend a month cleaning up the campground. They leave the campground a little bit better every time they use it and that’s what refactoring is really about. Spending a week to change those lines of code isn’t refactoring. Spending a week to change the code is reworking and that’s a different thing. Just as with TDD, there is a need to build up a skill and doing tiny, micro-changes that improve the code so that when it does deviate from what we now realize would be better, that we don’t stop all the work and slam it back into place. Instead, we just bear down a little bit and we make it better and we make it better and we make it better and we bring it back. If you think about what happens with a code base that’s pretty grubby, you don’t really have to fix all of it and there are parts that you should probably leave alone forever because you’re never going to edit there anyway. If we clean up the code and actually does things we can begin to do that a lot more incrementally and then, we don’t have to ask. I don’t want people to ask permission to do reworking because it is almost impossible for the business people to make a sensible decision about that because they have features in mind and features are worth revenue or features are worth happy users and all we have in mind if we’re going to do a refactoring is cost – “We’re going to take a week off and refactor,” – followed by this sort of belief that, “Yeah, but after we do that, everything will be better.” That’s a decision that no one should have to make. It is about building up a level of skill that is above what we have when we don’t really know how to refactor, a level of skill that will take years probably to get really good at. That’s the goal we have to set up for because rework is always too expensive.
Chet: One slice of that skill is noticing if the design isn’t what you wanted it to have been. If you build something and if you keep building on top of it and you discover the original idea was not quite the right one, it becomes often difficult to do that, but if you notice it really quickly… That’s one of the advantages of TDD. You have somebody there poking you and saying, “That thing we just did is not as good as it needed to have been. There’s a better way we could have done that and let’s fix it when it’s 20 lines of code before it gets to be 20 thousand.”
Sal: I’m just going to wave the diversity flag here as well because I think there’s something to be said, especially if you’ve been a stable team over time. What we’ve talked about with the Cucumber team is you stop noticing things after a little while. Maybe something’s a bit grubby, but you go and live with it today, you live with it next week and you keep living with it and then, you forget that it’s grubby because you’re all so used to it and then, someone like me comes along. “Hang on a minute. Why are you doing that?” That diversity, having that in mix, can really help, too.
Chet: As I’ve been thinking about diversity around the crafts, I remember back 20 some years ago at Chrysler, working with Ann Anderson who was one of the co-authors of the pink book with Ron and I. She would come up with ways of doing things that made sometimes no sense to me at all because she was thinking about the problem in a completely different way than I was thinking about it, and that was good because having a team that all think the same… Well, you have one brain and a whole lot of hands and that’s not as good as one brain for every pair of hands. You want to have people who think about problems differently than you do, who see the world differently than you do. Sometimes, it’s a little bit disconcerting, but it’s good. The value of that exceeds the little bit of confusion we have when somebody comes after a problem from a completely different direction. We get that at completely different levels. We get that with all kinds of diversity, whether it comes from experience, skill and gender and all the different kinds of things we can think about. Good teams have all those things. GeePaw Hill’s talk on Monday at Deliver Agile was about thinking about those kinds of things. You collaborate with people because they think differently than you do. If they think the same way you did, then you don’t need the collaboration.
Matt: This is one of the things I talk about a lot with people – about why I love BDD or ATDD, as you guys call it over there. Pushing the discovery of the uncertainty that you have when you start writing an acceptance test together before you’ve written the code and all of that flushing out of potential misunderstandings and different perspectives… When it reveals that I see this differently to how you see this, that gap is where there’s magic. There’s power in that gap between my perspective and your perspective. There’s power there to be harnessed and approaching that gap with curiosity, rather than with, “I want to win the argument. I want to be right,” is part of the skill that we all need to learn.
Chet: Collaboration is really about creating knowledge that didn’t exist in neither one of your heads or how many heads were involved. Building in that gap something that was better than what either one of us had that makes our understanding of the problem much more rich.
Ron: A thing that I wonder about often is how much of the conflict and often almost oppression that comes from young male programmers, and maybe older male programmers as well, how much of that fighting to be right instead of collaborating to be more right is actually coming from fear that I have to fight for my idea because it might be wrong. If my idea is right, I certainly will argue for it and I do because I enjoy talking, but I think that as developers gain broader experience and become more calm in their confidence of the things they know and the things that they don’t know and they’re okay with that, the better they do. I’m reminded of Ward Cunningham. If you asked him a question about, “How do you do this with Java?” he will certainly tell you, but if you’re working on something with him and you’re trying to figure it out, he will almost never give an answer. He will ask you a question that will help you discover the answer yourself. They don’t even feel like leading questions. They’re just questions that cause you to think about the subject in a little different way and after some time, you say, “We should do this,” and he kind of nods, knowing probably all along that you should’ve done that. I pride myself on the fact that I was at one time in one exchange so dumb that Ward had to actually tell me something.
Matt: He gave up. You tested his patience to the limit.
Ron: He kept talking about how to do this and this thing went on and on, and he finally realized that there was an idiom in Smalltalk that I did not know and he said, “Do you know how to write an interpreter in Smalltalk?” and I said, “I guess not,” and he said this and the three characters it takes to write an interpreter in SmallTalk and I was like, “Oh…” Then, we went on, but he never finds it necessary to argue for his ideas and he almost never finds it necessary to give you an idea. Instead, he helps you find that idea in yourself. I wish I could do that, but I can’t. I think that comes from confidence. He’s absolutely sure that it doesn’t matter if we go off on the wrong track for a while. We’ll be back. If we can find ways to make both junior programmers who may feel oppressed, more confident, but also the more senior programmers confident enough that they don’t mind going off the track for a while… One of the techniques we like to tell people in pair programming… People will say, “If you pair-program, what do you do if your pair has an idea and you’ve got a different idea? How do you proceed?” I always say, “Tell them that we’ll try theirs first,” because only two things can happen. One is that it will work just fine and then, you were the good guy who let them try theirs first and you can say, “Hey, that was really brilliant,” or it won’t work in which case you can try yours. It’s win-win. You let the other person exercise their ideas to the maximum. You can’t lose at it. you can only win.
Matt: We’re getting really deep there talking about fear. This is great! Inspirational! We’re at the end of the hour, so I want to call us together. If I am one of those developers stuck in the bowels of… What did you say? The insurance minds of Ohio? What can you say to me? What can I do tomorrow when I go to work? I’m driving to work now in fact and you’ve got me really riled up. What should I do today?
Ron: While you’re at work today, what I think you need to do is to try to get closer to having code that you can release, but I’m afraid that it will also come down to what you need to do tonight. You need to find at least a few minutes to find a way to up your game, whether that means to read a book, to find something on the web or to find a bunch of other insurance minders who would like to get together on Saturday and advance their programming. You can’t wait for somebody else to help you get better. You’ve got to seek out ways and that won’t be easy, but I don’t see any other way out of it.
Chet: I think I might say that a little bit differently. The good news is there is stuff that you don’t know yet that can make your life better and so, that just means you have to go find a few of those things. The fact that you don’t know them is good because if you knew them, there’s nothing to do. There’s no place to go if you know them all, but there’s a whole world of stuff out there that would make your life better. We’re finding stuff that makes our lives better. That’s why we still go places and talk to people and hope that they can teach us new things and that kind of keeps us interested in all this stuff.
Matt: It’s been wonderful talking to you both. It’s been a really interesting conversation for me. I could talk to you all night, but I think we ought to call it a day now for the listeners’ sake. Thanks for being with us. Goodbye!