2. Not too bad. So you’ve got the part, you’ve wearing the hat, because we’re in cowboy country, right?
Well it seemed appropriate for Nashville.
Oh, from the start of it how did g get to the Agile community? Originally I went to work for a company and they brought it up and said “oh, we’re Agile”, I said “well, ok, that’s good, I better read up on these Agile practices” and I started reading up on them and two things happened, I realized this is the way I’d been working for a long time, I just never knew there was a name for it. And secondly I realized that the company I was working for definitely was not Agile, it just was basically putting a poster on the wall. But it really caught my attention that there is a community out there that worked in the way that I liked to work already, quick interaction with the customers, getting the feedback, so I dove right in and I pursued Scrum training and I got my Scrum Master, I’m a Certified Scrum Professional, and I began working in the software, getting people to work with Agile practices, bringing in some XP practices, I just got fully immersed. Also, I started getting involved with the Agile community in Ottawa, working with them, now I am one of the organizers for Agile Ottawa and I guess from that it has grown to getting more involved with that, going to a conference, turning points along the way like seeing Uncle Bob Martin in a session and realizing how much my code stunk and how much better I could do it, which I thanked him afterward, for opening my eyes. That really got me involved in more craftsmanship.
But as I went down that road I realized a lot of people that wanted to do this, but they didn’t know how and they had a lot of trouble cracking that. I’ve done a lot of teaching in the past, tutoring and different things, so I started developing ways to teach which leads me to this session where I am doing Test Driven Development with Lego.
Craig: Excellent. I’m going to come on to Lego in just a second, but we met back, I think it was one of the early Agile Alliance Functional Testing Tools workshops.
Actually, I think the very first time we met was when I went to my first big Agile conference and I walked in and I was looking like somebody completely out of their element and you said “hello” and introduced yourself, so you were my first actual contact with the larger Agile community. So, thank you for that.
I think the Agile community has grown very strongly in doing things like organizational change, the people attending now, you’ve got Project Managers and you’ve got Business Analysts, and people who were very far away from it, but at the same time what’s happened is those technical practices that XP brought, those were disappearing all over the place, there are people who are doing them, I am not saying people aren’t doing them, but there is a large amount of developers who are still following very poor practices. It’s shocking, but already at this conference I heard a guy asking about source control, “should I have source control?”
I am not letting it fade, I am saying “XP not dead”, that’s my new phrasing, if you see it graffitied places, it wasn’t me. XP not dead, people might be turned off and say “this is too much”, even the word extreme might threaten them a bit, but they need to dip into this, the developers need to have a higher standard, higher quality, we need to pursue craftsmanship.
Craig: Absolutely. I want to explore a little bit about the fun and things, but you’re holding some props there which I will let you get rid of. So you’re here at the conference to talk about, to demonstrate a different way of thinking about refactoring and TDD through using Lego. So that’s your talk at the conference, tell us a little bit firsly how that session came about.
The session came about as I tried to talk to people about TDD, actually myself having a hard time getting my head around it, I programmed, I’m old enough that I wrote my first piece of software in 1978 and that was a very basic thing I was doing.
6. Out of the back of a magazine?
I was very young, yes, I loved going through manuals and typing in everything, so for me to now go and say “wait a second, now I’m going to do my test before I write the code, it’s counterintuitive, it doesn’t make any sense”, but I knew that it was a good practice and so I was persistent and I tried and I tried to follow things online, but the computer seemed to be the barrier, the language seemed to be the barrier and I just wanted to get my head around the concept, you know have the proverbial light bulb turn on. So then I went to a session by Ellen Grove, she’s from Ottawa as well, and she was using Lego and then I was in Agile Games in Boston and they were doing this Lego presentation and at that conference I said, I put up in an open jam, I said, “hey, let’s try to figure out doing Lego with TDD”.
And I got about 15 people in that session and we were at a great facility, the New England Research and Development place at Microsoft, so you can write on the walls and everything, full whiteboard walls and we coughed out a couple of ideas, mostly about out of ten ideas we probably had eight stinkers, but there was two things which were probably pretty good, and I couldn’t quite form them into ideas, but I let them ferment for a while and probably ten months, eleven months after that, I kind of had a flash of inspiration one morning and I went and I grabbed some Lego and I started putting together and the ideas started forming for doing the Test Driven Development portion of it. And then I play-tested it on my children, they at first were asking questions, so I iterated through, I made some adjustments and then they were getting it and understanding why we would want to work this way.
And then at that point I followed up and did a different technique for refactoring. So, after that, I started presenting it to people and they loved it. I presented it in San Francisco and in Toronto and some universities now have picked it up, presenting it and I am going to get the whole thing organized as a Creative Commons license, because I want to share this with the world, I want people to do TDD, to learn it, and then there is a lot of other experts out there teaching TDD on their computers and that and there is all kinds of sources out there. But it’s that first step, people are trying to go from lying on the ground to running and we have to teach them how to crawl and how to stand up. Once they get those basics underneath them, then they can be off to the races.
The nice thing with the Lego is you don’t have to be a developer, you can be a Business Analyst or a Manager, come on in, I invite you to come in and explore it, it’s wonderful because you can hold software in your hand, which you can’t normally do, and it’s tangible. And something magical happens the moment, I have bags of Lego, the minute you have this Lego in your hands, you can turn the program around and view it and it becomes a tangible thing that you understand and appreciate and you look and look at it and say “this is complicated, this is a fragile, complicated thing” and all these words that we used to use, but have dropped out of our vocabulary start coming back, so it’s a fascinating thing. People get emotionally involved when they start being tactile and using with their hands, and imaginations come out and all of a sudden they start having fun and they don’t even realize that they are learning something, it’s just a bunch of kids again, playing around for the duration of the session and then they get up and leave and they go “wow, I understand TDD and refactoring”.
Craig: So roughly, how does the session work, you get a bag of Lego I assume which is the building blocks of the system tat you are trying to explain.
These are all, I don’t have the specific bags right now, they are all mixed up right now because people were playing with it out in the hall, but we start off and we build the program with the Lego as opposed to writing code, we add Lego to it.
8. So there are requirements or stories on what you need to build?
What we do is take paper and take a pen and we write a test, we write a test out and then you have to fulfill the test with the Lego. And the importance is we teach people that to do the minimal amount there is.
9. What would an example of that be in the workshop?
You’re making me give away stuff before the session. We ask people, when they first start, I let them loose right way and I say build a man and a house, and so you get all kinds of great parallels with the software community that happen. For example people build these beautiful houses, gorgeous house, lots of detail, chimneys on them, windows and there is no man. I say that is a beautiful house and I will pay you zero for it because there is no man to go with it, you haven’t met the requirements, I can’t sell this to the customer, it has no value. And then there is other people that use every single piece of Lego in the bags, very, very common and that’s a parallel with our gold-plating of software, so the important lesson people learn there is about just doing the minimum and then they start to see what it looks like, how different their “software” looks like and their software is their Lego creation.
I think there is this mind-opening moment when I tell them, first of all, they have their programs and I tell them to clear a space in front of them and I tell them that is the best program in the world, the best program ever, optimum program right there and they get these questioning looks and I say because it has no bugs in it, it runs super-fast, I say if we don’t have a problem, we shouldn’t be writing code, we’re writing code to solve problems. So then we start off with a basic test and they do something very small and they say “does it pass the test?”and we go “yes, it does”. So we have a lot of little jokes and stuff in there as well, there is a lot of cheering, it’s a very high energy session. But they see it right there, they are saying “wow, I didn’t have to create, no one said that my house had to be three-bricks high, or this wide, or that, the only requirement I had was a house” and a simple brick could be that, so it’s all representations, we’re not building actual houses out of Lego.
It might be, that might be good enough. What we do then is we start layering on the complexity. So we say “ok, well let’s say the house has to big twice as wide as the man”, and it’s “hooray, we have a failing test” and that is a very important thing that we, that I get in there is to say, I’m saying we because you go to so many different sessions and you see this coming up, people talking about the importance of failure in learning, if you are not failing you’re not learning, you’ve got to go to your environment, you’ve got to remove the fear of failure, you have to say “it’s safe, it’s ok to make mistakes”, we are going to make mistakes early so we catch them so the ones that see the mistakes are us and not our customers, so that way it doesn’t cost us money.
12. And TDD, I guess, is the smallest unit of failure really isn’t it, and learning?
Absolutely, we can learn very, very quickly. We write a failing test and then we pass it, and then we refactor to clean it up and remove any duplication. I keep things very, very simple too, there are some very large books written on refactoring, some great ones, like Martin Fowler’s book, it should be on every shelf, it’s fantastic. And there is some great stuff on TDD out there, I use Kent Beck’s By Example book, thank you Kent, very, very much, and it would be the greatest honor if I ever got to do a session for him but I hold his book up at the beginning of the class, because basically I’ve taken what he is presenting in the beginning of the book and do it with Lego.
Craig: It’s the baby steps of the process.
The baby steps and he keeps things very, very simple and clear and the message is there. It’s quite interesting you can see how other people teaching TDD have sometimes deviated a little bit from what that original and earlier message is, and I go back to his message and I use that. And I think that helps too, keeping a very simple message, we are just going to learn a little bit today. If you try to learn too much in one day, people can’t process all that information.
Craig: And this also extends to refactoring as well, this exercise where you can also demonstrate once you got these tests and making sure you’ve got now what you expected and that can also, I assume, move forward to refactoring just to show how you can improve the design of the system without affecting the test.
The refactoring is a little bit different, I use a bit of a different technique, again with the Lego, but we do a different process and people often ask me “can you give us some bigger bricks and stuff?”, but I do it very on purpose I give them small bricks that are hard to work with because I want them to feel like they are writing software. It’s difficult, we don’t just go through this easy experience, I want them to struggle a bit and get engaged by having to focus on what they are doing. With the refactoring one, its focus mainly is on showing removal of duplication, so try a method and don’t repeat yourself, and we focus on that and again keeping things very simple.
Craig: Thanks for sharing that and I hope it’s a full session and that you do get your world domination of people understanding TDD, because it’s one of those things that I still think so many people think they understand, but don’t.
Well, people always talk about Test Driven Development, but a lot of people call it Test Driven Design, because what you start to learn after a while is that TDD is not about testing, and what it is about is the software needs revealing how the code should be written, so designs actually emerge and that’s the really scary part in a way for developers is after they start doing TDD for a certain amount of time, they get another “aha” moment where they are like, “wow, this is different”. In fact, in Kent’s book, he says that he’d done the same talk and done the same example 30 odd times but when he went to write the book a new solution popped up in front of him and he went in a different road. One of the things he says is if we go with the first solution, we will never find a better one.
13. [...] Why is that so important to you in your teaching and your work with teams?
Craig's full question: In that kind of vein, one of the things from having known and met you at these conferences when you pop up, is I always see in the open space areas of the conference you are always interacting with people and making things fun and I guess that’s something we’ve spoken about before, you really do have this desire to help teams and get them perform, but that fun is underpinning all the things that you do, why is that so important to you in your teaching and your work with teams?
I think partially because I am an extrovert, I have a lot of fun being around people, it gets me in a good mood, I love interacting, I love exchanging ideas. I’ve always been a mentor and teacher and I enjoy that a lot. I guess it’s because I’ve had some fantastic mentors and teachers, people that have taken very good care of me and helped me, introduced me to new ideas and so I feel it’s appropriate that I do the same. I do enjoy it, I’m not just doing this just as a good deed, I get a lot out of it and if you know anybody who teaches a lot, or if you teach a lot yourself, you know that wonderful feeling you get when someone else has an “aha” moment that you caused. That’s extremely rewarding.
Now you’re going to have a great deal of laughter from that one because my current team is mostly introverts, a lot of software developers are, they want to work on a computer and focus, they get exhausted actually with a lot of interaction, and all the things that Agile has brought has been very tiring, and people will do things like bike home so they can have a bit of quiet time afterwards, they have that alone time so the introverts can recharge. I find sessions at conferences like this very hard, in a way, because there is so many people, I get my energy level jumps right up and then like a session will start and there’s down to very few people and then I have this energy crash, it’s kind of up and down, up and down happening, makes for an exhausting week but it is a lot of fun.
The biggest trouble I have is really being quiet, because as you’re hearing already, I will talk and talk and talk. But I have to create a space for them, create space for introverts so they can state their opinion. I think when a team gets to a certain level of trust, that comes out more, and people talk openly and people will say “let me finish” and we’re funny because the way we talk, we sound, an outsider would think we are very abrupt with each other, but we are not at all. Everyone knows that no one is upset at anyone, we’re just discussing the ideas and we have lots of passion. I haven’t seen it really as a problem, maybe I’m a controlled extrovert in that way, but I am mindful that other people aren’t the same as me though.
Craig: Excellent. So, one of the other things I wanted to bring up was you’ve been playing around in the Lean Startup space, you’re working for a new start-up called Fusebill, tell us a little bit about that and how you fit into that as an Agile software developer.
We are all Agile software developers there, so that’s a critical thing, I wouldn’t be there if it wasn’t for my Agile background, specifically the Development Manager approached me because of my Agile background. Everyone there does it, we do TDD, we’ve adapted, we have a lot of focus on adaptation, so in the retrospectives we’ll look at our process, our wall is constantly changing and how we use it and any suggestion is looked at, anything the team offers, the team really drives the process, so we’ve got a wonderful group of people. In short, we do software-as-a-service, we do recurring billing, so if you had a monthly billing service, say you’re charging for your Agile coaching and people pay $20 a month, we could take care of all your billing needs for you, handling the credit cards and invoices while you can focus on your business and what makes you passionate.
Well, some of the people were there, some of the people are new, we have a mixture, very much so though I think having the right people on the team is important, sometimes it doesn’t work out, that’s the reality, you want to get the right team together, you want to get the right people to interact, I’m a big believer in the importance of those interactions that people have.
Craig's full question: That’s also something that I wanted to explore because in previous sessions at the conference and just a lot of your tweets and writings the importance of team is something that I think you hold to heart and I guess to make sure that comes out in the teams that you either coach or that you work in. What are some of the secrets behind that, what are some of the things that you look for when either working in a team or creating a team to get that type of culture?
There are some key, basic things like when you see these words pop up again and again, words like trust, safety, respect, you have to have this on the team, you have to create that environment and you need to work at it continually, people need to be able to speak their mind openly, otherwise you might miss out on a great opportunity. I think knowing that people are safe to state their opinion and they are not threatened and they can work the in a way that they want to work, you shouldn’t force people to work in a specific way either, you want them to work with you, I guess what I am trying to say is it’s good to merge what you think is ideal with what they think is ideal and if you can get people that can collaborate and work that way together, then you are off to a good start.
Depends on the team, your approach is going to be different, I think you need to show people the value of the tests and you need to show people how it can save them time and sometimes simple things like when a problem rises up you can just drop little lines like “it’s too bad we didn’t have test around that” and what we do is to fix it, pair up, write the unit test so that it doesn’t happen again.
Craig: It all comes back that fail fast type idea.
Yes.
Craig: One of the other things, in fact I only just learnt about this when I started speaking to you before the interview, you are now starting to apply this whole idea of refactoring and Agile practices or XP practices to the human body in something you are calling human refactoring, sounds really awesome, tell us a little bit about that.
That’s my current passion right now, the human refactor, go to humanrefactori.com, there isn’t enough content, but I am working on it, I’m a bad blogger, the whole idea is to apply these XP practices to our body so looking at it like Test Driven Development. For example, I still run five kilometers every week, but I took my time and I set a reasonable mark and I said “ok, 30 minutes”, and I ran, I had a failing test, my time was like at 34, so I said “how can I get my time down?”, so I went online and I learnt and I researched, not just training physically or eating better, I actually read about running techniques and there is a technique that people even use in marathons where they alternate between running and walking, so what they had for this one, they said do a four minute run and then a one minute walk, it allows you to get your breath back, your heart beat goes down, you rest up a little bit and then push yourself again. And so just by changing to this different process, it involved a bit of sprint at the end, but I had the energy to do that and then I had a time of 29 minutes and 48 seconds, I didn’t do it in 20 minutes but I got a passing test. The idea is you then set a new bar and what do I have to do to get to that bar and then again try to do the minimal you can to get to the goal.
19. That’s TDD, what are some of the other ones that map out?
Refactoring is one that comes up, if you look at your body and your body composition, people will go and stand on their scales, that’s one measure and it’s a pretty bad measurement, in fact, because muscles are heavier than fat, people have to look at who they want to be too, it’s very important, I don’t want anybody to say “this number is the critical thing”, what you have to is decide once you have again your goal and say how can I do that, how can I achieve better goals, my thing was getting to 10% body fat, so I look at that as refactoring my composition. And so doing that I changed my diet dramatically, I don’t eat any wheat, I haven’t for over two years, I’m 44, I play soccer, there is two 20-year-olds on the team and I was up until last week I was tied for the leading scoring. So I am able to contribute and be a big part of the team even though I am twice the age of some of the guys, there is no way I could do that if I hadn’t been able to refactor myself.
Craig: If you think about it, it’s very much like an Agile software team in that respect, you pick the measure, we talk about velocity in Agile teams quite a bit, and how it’s not a good measure even though we teach it in 101, you’re talking about the same thing here, that weight is the obvious measure and the one that everyone strives for but actually you usually have no hope in achieving.
People also look at it and say “I am this weight and I want to be this weight” and it took them 20 years to get to that weight and they want to be down at that other weight in ten days, so there’s this realization of achievable goals that people need to go through. So human refactoring I’ve talked about some of that stuff and presented in open jams, I did a presentation in San Francisco about it, talking about all the different aspects and goals you can do with people. What is an interesting thing is that people go “yes, I want to do that” and then we start talking and these barriers go up and they go “yes, well, I can’t do that, I can’t make that commitment”. I have a colleague who is now a week and a half into having no wheat, he’s trying it because he is exercising all the time and he is still not losing weight, so he needs to try something different, so I am very excited about that. But it’s something I have to work on, I have to find out how to get people past that point, because you need to internally say “I want to be here, I want to do this, I want to quit smoking, I want to exercise more”, I can’t magically wave a wand and give you that, you have to internally say “that’s what I want to be, that’s what I want to do”, now I can coach, now I can help you, I can give you all kinds of techniques to get there. But you can’t tell someone to quit smoking, they have to decide to quit smoking.
Craig: That’s no different to software, you have to make the decision that you want to take the product in this direction or change the database or eliminatetech debt.
I think commitment is the word, I am going to commit to write unit tests for this whole section, let’s do it.
Craig: Absolutely... Let’s talk about some of those core XP concepts.
I think there is not enough development going on here at this conference. I think there is a large amount of stuff to cover, this is why I didn’t come last year and I came back this year, but I am not seeing it, I’m seeing a few coding sessions, but not enough high end coding sessions in a sense. This is an opportunity for the Agile developers to come together and maybe invent some new things, make up some new stuff. Years ago in Chicago we were talking about what to do when you have 20,000 unit tests running and it just takes so physically long to do that, so solving advanced technical problems, but I don’t see those sessions here now. So that concerns me a bit, which is why I keep bringing up XP, and people say “oh, XP is long gone”, but what that means is I can’t make money as a consultant if I say I’m an XP coach, no one will hire me for that. I know people have to make a living and all, but if you are not bringing these techniques into the team, then you are doing them a disservice.
Craig: And I wonder, one of the reasons, and I completely agree with you about XP, I am always reminding people of it, some of the things I hope in XP have become common sense, you where mentioning the version control person, and I am hoping that’s a small minority of people here.
Scares me all the time, my friend told me, he had a very good word for it, he said “unprofessional”.
Places like Facebook are doing continuous delivery, so don’t tell me that your company can’t, they have running things through one branch, there is no reason why we can’t do that. I think a lot of times people are afraid to go out of their safe zone and often times they are being pushed to “we have to release more stuff, we have to get the features out there” and because of that it’s difficult to change and to improve. But one of the first things I learned in getting involved with the Agile community was if there was only one thing you were going to do, only one thing, it should be retrospectives, because if you don’t have the continuous improvement, you’re missing the point to all of this.
What should we be talking about? That’s a very good question. I think we should be talking about raising the abilities of our developers. At the end of it, all of these people here, we are trying to create software, that’s the common thing, but we are not talking much about creating software. We are talking about some good stuff, which is delivering value to the customer, that is the focus of a lot of things and a lot of the developers, maybe that’s what would be good is tohave the developers get a better appreciation for the fact that their stuff has to go to a customer and if the customer doesn’t like it then they don’t have any money for their job, that reality is important, so if we can write software that way, write software to be delivered as opposed to writing it to work inside this nice framework which allows us to writing software for the sake of software. It would be very dangerous, we need to stay focused on what’s the minimum to do to achieve the customer’s request. And I think we got caught up in the romance of this language versus that language or “we have to find the solution in Ruby or in Python”, you don’t. Joshua Kerievsky, he had a great presentation in San Francisco, he was talking about being a hackerpreneur, and he’s like“just deliver it, whatever you know, whatever you know best to do, that’s the software you should be working in, whatever you can turn around things the quickest in, that’s the language you should use, just deliver it, meet their goals, do what the customer wants”.
22. Which goes back to 1978, that was really what you were doing?
Yes.
Craig: One of your other passions is music, if I go search your Twitter handle that kind of leads me to that, tell us a little bit about your passion in music.
Music, I just spend a very long process building a music room in my basement which is wonderful and I play music in a band, Billy Garnet is my stage name, also my Twitter handle. They got a picture of me last night playing guitar here in the lobby; we had somebody bring their guitar up. It’s a big part of my life, the music, it allows me to get any emotional energy out. I play soccer as well, so the soccer and the music combined allows me to get anything out, it’s my output, it’s art, no matter what life is giving you if you have some artistic technique to output into, it helps keep you sane.
Well, they can go to billygar.net or humanrefactor.com, those are both in the same spot right now, but I am going to do some work there. Also @billygarnet on Twitter, that’s a good spot too, and if you look up Fusebill, fusebill.com and if you contact them, they can get a hold of me.
Craig: Excellent. Thanks very much for your time.
Thank you very much, it’s been a lot of fun.