 Can you hear me, even at the back? Is it clear enough? Yes? Okay, thank you. So I hope you had a very good lunch. And welcome to our workshop today about test-driven development and peer programming. So my code there. Okay, so here's the Wi-Fi code, we're gonna need it. So please connect to this one. And if you haven't given your GitHub username, please do so now at the desk over there. We need it to add you to a GitHub repository to be able to push later on. Some logistics. So there will be, there's some snacks over there and some drinks. So if you're hungry or thirsty, please help yourself. On your table, there is some goodies from Palo IT. So you have a notepad, you have a pen and metallic straws. So this is for you. And we're gonna be taking some photos today. So if you don't like to be taken in pictures, please reach out to Chris, or is Chris over there, that you don't want picture taken from you. That's pretty much it for logistics, so let's start. So welcome, as I said, about TD and peer programming today. So this is gonna be an introductory workshop so for beginners. So I hope there is not, all of you are not all experimented into that. If not, if yes, maybe you learn some new things. So today agenda, so we're gonna start with a check-in. Then we're gonna give introduction to test-driven developments. We're gonna introduce to you a report dashboard. You're gonna see why later on. Then set up your machine to be able to do the exercise and I'm gonna do a quick demo of test-driven development. Then it's gonna be your turn to do the exercise. So we're gonna have maybe 40, 45 minutes of exercise with TDD, then a small debrief, all together. And then we're gonna have a small break, about 10 minutes. After the break, we're gonna do the same with peer programming. So first introduction, then a small demo. And then you're gonna do the exercise for about one hour. Then I get on the brief and we're gonna conclude with some resources. Today, with me, so my name is Kevin. I'm technically at Palo IT. I have Ken, so agile coach at Palo IT. Amul, full stack developer engineer. Vidaba, DevOps and cloud engineer. Elniton over there, full stack engineer. And where is Anil at the reception desk, full stack engineer as well at Palo IT. So Palo IT, I don't know how many of you heard about this company. We are a consulting company, international. We do development. We have URUX, Agile, and DevOps and cloud. We are about 115 Singapore. So if you don't know us, just go to PaloIT.sg.com or .com.sg and you find us and you can learn more about us. Check-in. So I invite Ken for the check-in. Do you have a mic? Yeah. So I hope you guys can hear me. It's a bit loud, but I understand you might be able to hear me. We go to the first check-in conferences where we use this thing called bandit leader. What I would like to get within the group is to get a sense of your experience with T-80 and your experience with air programming. So if you can, go to this website, www.mattina.com. Use the code 399263 and then answer this first question, which is what is your experience with T-82 that's really fast? Okay. This is not fast as in your first, but yes, please come to this. So let's see. We have about, oh, less than 15 now. I know what it is, but I don't know what to say. We are stabilized. So what this means is, as Kevin has mentioned, this culture for TV is for introduction. For those who know what it is, but have never used it, maybe you can use this culture as a way to pick up, to match it with what you know. I have to see if there's any gap. Perhaps there's some that you actually know more than what they share, that's because women are very introverted and that's okay. Try to pick up as much as you can. 24% of what I've done for less than a year, good for you, and I can assure you continue to do more, so the next time we will do a check, it will be more than a year. And for the 6%, and this is a skip, but it's not long enough, okay? And for those 6% of none, welcome to this enjoyable, well-attached women development. You change your life. Let's go for a second question now. So what has been your experience with hair programming? Three, two, three, four. No, after that, I'm going to speak the whole way to the group. It's just for this part. Okay, it looks like it's stabilized. So that's the deal of this year, we're never telling you off. And as Marky already mentioned, we do the hair growth exercise to review stuff and get a sense of how it is. For those who did it and did it, I hope by doing this session, it can help to see why it didn't work out for you. Let's try again, we'll bring something. Did it, and I can live with it. Okay, that's the deal. And the three persons who passed by default, that's very interesting. Okay, I don't know about you, but in my experience, when you're in hair growth or long enough, the moment you actually go on the road, you may feel uneasy. And I think these three persons who passed by default will have that. But it's a new thing in the exam, I think. All right, so let's go for a check-in on the steps where we are in this group today. All right, I'll have the time back to tell you. Thank you, Ken. So, test-driven development, what it is. So it comes from extreme programming, which comes from agile. So some of you know scrum, I bet. So extreme programming is a different branch of it. So Ken Auer, from the book Extreme Programming Applied, wrote this code. Writing test first keeps entropy from destroying your code. We write test, then we write just enough code to get a test pass, no more. That is the best way to keep your code clean. So what this means is the idea is really to write a small test, small as possible, and then to write just enough code to make it pass, and so on, and so on. And this avoids your code to become a mess. And this gives you a good structure in your code. So, as I said, this is the gospel of TDD, but Ken Beck, Ken Beck, another author of Extreme Programming. So write a little test that does not pass. Compiling, not compiling, is not passing as well. So that's completely fine. We call this the red state. So the red state, very important. Then, we have to make the test pass as quickly as possible, even if we have to write messy code or committing sin. We just have to make it pass, that's it. This is the green state. After that, once it's passed in green, we eliminate the duplication, and we rewrite the code to make it nice and clean. This is called the refactoring. And then we repeat these steps over and over until we arrive to a satisfactory result. Again, if you forget what TDD is, remember this. Red, green, refactor. Go ahead, make it run, red and green. So, writing a test that fail, making it pass, it runs. And then, making it write. So we refactor the test and the code to make it clean and nice for other developers to look at it. Some people have asked me, okay, what is refactoring? There is a lot of answer to that. So I invite you to look at this website here. It gives a lot of example of what refactoring, a lot of example is very good with scenarios and when to do what. Just some examples, so very obvious that most of you do it already, is just putting a name on it. So you can extract the function, you can extract a variable, introducing an explaining variable, you can rename a variable, for example. You can introduce a parameter object or replacing loop with pipeline. So those are just five examples amongst a hundred or thousand of them. Now I'm gonna give the mic to Vidaba over there so you can just look on this side. Vidaba, all good? We need to commit our business source to meet your data level here. Why Vidaba? And it's going to run in continuous integrations. And you can see the code coverage result on the screen over here. There is more of a way to make sure this is a centralized location for us to monitor how the device progress with the test results. You can also look at this result, look at it as well, however, it's hard for us to put each one of you in there by the different. Other than that, we would like to see everybody who has some problems with it. So that's very important for me. You can also see that you can do a test by using a particular code. Say for example, this one, master over here. And this is the new data of the test result. You can also see locally as well how we run that. We run our data, so we want you to verify. Other than that, we have some problems here. And please try to meet the code coverage of 80% of the code, which is the test we run over here. And also, try to meet your code coverage as well as the problem of getting high end for people, so that they can see the progress, yeah? And it's finally gone, and it's finally been modified and we can't see the result. We didn't manage to go back time. Thanks a lot. Thank you, Vidava. So the idea of the dashboard is industry standards, more of the clients or company they ask for 80% or above of code coverage. The idea here is to show that TDD is quite easy to reach that numbers. If we do the opposite, meaning we write your code, and then at the end, oh, I need to write my tests, it's gonna be very difficult to have clean tests and to reach those 80%. Or you're not gonna write a test that needs to be written. So this is just a dashboard to see, okay, it's very easy to integrate in Jenkins and to show your coworkers, colleagues, or even management, okay, my code coverage is 100 or 80%. Okay, now I'm gonna do a demo of what I just explained before. So I hope that some of you know the FizzBuzz exercise. Who knows it? We have three, four, five, okay. So this is a very famous exercise that in interview, been asked a lot. So it looks very simple. I'm gonna show you how to resolve it in TDD way. So if the input is a multiple of three, you return Fizz. If the input is a multiple of five, you return buzz. If it's of three and five, you return FizzBuzz. Otherwise, you just return the number that was given as input. Quite simple, right? So, let me take a chair. I'm gonna zoom in, no worries. So this is the code you're gonna check out later for the exercise. So you can see the package just Jason is quite simple. We just have Babel for transpiling. We have Jest for the code, for the test, and that's pretty much it. That's all we need. You have a folder with example that contain the basic function and it's corresponding tests. It's just for you to get the syntax because some people are struggling just to get the syntax of Jest or so whatsoever. So you can just copy and paste from there as a guideline. So coming back to the FizzBuzz exercise. I'm gonna first create FizzBuzz directory. And inside this one, I'm gonna create two files. So one for FizzBuzz.js is gonna contain my function and one for my test. So by convention, I'm gonna name it exactly the same, the test.js. So on the right side here, you will have my code. So let me zoom in. Can everybody read? Is it big enough? At the back? So my function FizzBuzz. Gonna take, I'll say input as argument. I'm gonna export and that should be it. And then I'm gonna write my test. So I'm just gonna copy and paste from the example to go a bit faster. Here, input. So this is the name I choose to give to my input. So FizzBuzz and that's pretty much it. Oh, sorry. Okay. Let me move that to the left. Okay, difficult to go that big. Okay, so I'm gonna describe my test suite. So FizzBuzz testing suite. And thank you. I'm gonna start by, so. Where is it from here? Sorry. Just, whoop, my bad. Here. There's something wrong there. Oh, sorry, yes, sorry. Oh. Bending too much Java lately. Okay, so it should, should return one when one given a simple. So I expect given one to be one. So this is the simplest step I can think about at the moment. So if I run it, we can see it's failing. So now I'm in the red state. Now the next step is to make it run. So make it green as fast as possible. So I'm gonna do return one. I'm gonna make it green as fast as possible is green. Now I'm in the refactor. So refactor, I think for now it's okay. I don't need to refactor, there is not much code. Now next one, next test. So what is the next test that will fail my code? So show return two when two given. So input two to be two. Okay, I run again and of course you'll be red. You'll fail. So now again I'm in the red state. So now to make it past as fast as possible. If two, return two. Sorry, it's integer. Now it pass. So now I'm fine. Do I need to refactor now? No, I think I'm good so far. So let's continue. So now next one that will fail if I continue this way. So now three, three should return fees. Again, I'm running my test. It should fail, which it does. And again, if input three return fees with uppercase. Hopefully it pass. So I'm in the green state. So now I can refactor a bit. Okay, I'd prefer to have those brackets because it's nicer. And here I can have else with some brackets. And now I like my refactoring. I run my test to ensure that it still pass. Okay, I didn't break anything with my refactor. Now what's the next test that will fail my code? So show return four when four given. So input four to be four. I run my test. And again, I'm in the red state. I hope you are there all afternoon. I'm gonna go to 100 like that. So now I'm in the red state. So again, to make it fast. So for four return four. Four. And now we pass. Okay, now I can say I have a tendency whenever I have a number except three to return this number as a string. So I can see there's a repetition. So it makes sense now for me to rewrite my code in a better way. So if it's not three, basically I need to return the input as a string. I'm gonna do it this way. And this I can remove. And this I will remove. Now I'm gonna run my test again. And it's green. So my refactoring didn't break anything. Now the next test that will fail my code will be five. So five return buzz. Remember if it's multiple of five, I need to return buzz. So when you put is five, I expect buzz. So again, if input five return buzz with uppercase. And it passes. Can I refactor something now? Yes, maybe I would like the else here. Make it nicer. And maybe the test I can refactor a bit better. I will say now, I can see I have a tendency before when I give a number, I should give this number as a string as output. So I would like to refactor as written the input number when not multiple of three and five given. So I have two here. I have four as well. So now I can delete this one and I can delete this one. And I will still ensure that everything pass. So I'll say before refactoring is not only on the code side. It has to be on the test side. Otherwise you get a mess very easy. Code is important, but test is as much as important as the code. Now, next one that can think of to make it my code fail will be six. So six need to return fees multiple of three. So input, whoop, so fees. Now I'm going to make it runs. It should fail. And here, so input three or input equal six. So now I can see here, I have like a if that tend to be lengthy that will start increasing. So I decide to refactor now. I can see that so multiple of three. So if my input module three equal equals zero because it makes sense for me now to refactor this part because I have test that tells me to do it. I return fees. I ensure that I didn't break anything. Okay, still pass. Now I continue. So next one that can fail. So multiple of three, so nine, no, it will not fail. So with the next one, 10, multiple of five. So input 10. Sure return buzz. Again, I make it run. So I'm going to be in the red state. Now I'm going to be in the green state by making it past as fast as possible. So or input equal 10. And I'm in the green state. Again, same, I can see I have a tendency. It's going to add more condition in the if close. So I'm going to refactor that. So five equal equal zero. So to ensure that whenever it's a multiple of five, I return buzz. I'm going to read it again. And here I'm in the green state. So can I refactor something? Maybe in my test, I can see here I have a six, three, five, 10. So here, so I should return fees when multiple of three given and same here. So return buzz when multiple of five given. Now I can delete those. And I will run to make it sure I didn't break anything. Okay, it's still green. Now what's the next test I can write to make it fail? Remember the multiple of three and five should return fees buzz. So should return fees buzz when multiple of, when I would say when 15 given. So when I give 15, I need to run fees buzz, to return fees buzz, sorry. I run and that should be in the red state. Now again, if input equal equal 15, return fees buzz. Okay, that is green. Now I can refactor. Again, I want to use the else because I find nicer. That's all I can do at the moment. So I run again and I didn't break anything. Now next test that can fail, 30. So fees buzz when 30 given. So 30 should be fees buzz. Gonna run my test again. And I'm in the red state. I'm gonna do this. Or input 30, return fees buzz. I'm in the green state. Now I can refactor. So again, I can see a tendency of repeating is still gonna increase the more test I add. So I'm gonna do that. So 15 equal equal zero, return fees buzz. Okay, pass. Now I'm still not satisfied because the statement says multiple of three and five. So I prefer to do it this way. Where's my N here? Because like that, when the developer read the code, you can see, okay, multiple of three and multiple of five. So it's clear as well to understand. It still pass. Now again, I'm gonna refactor my code, my test. So I'm gonna group these two together for multiple of three and five. So return fees buzz when multiple of three and five given, I'm gonna run my test and everything is green. Now if I continue, I cannot think about any test that will fail my code. So I decide that I don't have any refactor to do. I could do a bit more. I can extract variable. I can do a name variable. I can create sub functions. But I think for the purpose of the demo now, I think I'm good enough. I'm happy with that. So I can push and commit my code. Now, if you look at the result of the test here, can I zoom in? No. I don't know if everybody can see that. It's a bit small, right? So just to explain, well, I mean by just by reading the test, you can tell what the code is doing. If you just read that, you can, you know what the code is doing. So sure return the input number with not multiple of three and five given, sure return fees when multiple of three given, sure return buzz when multiple of five given, sure return fees buzz when multiple of three and five given. So just by reading this, you know what this is doing without reading the code. And this can be understood by everybody, not only developers. So this is a big advantage of TDD and writing proper test as well. Okay, I'm good for the demo. So let's go back to the slide. So how is this useful? So it helps to understand the problem statement. As I said, rather than coding directly the whole problem, you have to break it down to very small pieces. It looks tedious at the beginning, but once you get used to it, it brings a lot of advantages and helps to resolve more complex problem easier. It gives a better design because every line of code you write is because a test tell you to write it and not because you want to wait for any kind of reason. It helps, of course, define the current state of the system behavior and it gives you a full suite of tests to ensure system sanity. Meaning by having this, I have like 100% of light coverage. So I ensure that my code is tested. So nothing will break it and I got a regression test as well with that. Okay, now I don't know if you have any questions so far about the demo, something that was not clear. Otherwise, we move on to you, Pat. So now it's your turn. I ask you to clone the following repo. So we added you on the GitHub so you should have access to this one. If you have any issue with that, let us know. So as a reminder, there is Amul, Vidaba, Elnayton, Anil, Ken and myself that can help you with that. So once you check out the repo, please create your own branch with the following naming. So TDD slash your name or username or you decide. Then you can open the code in your favorite IDE and run just npm install to have just and everything configured on your machine. Once this is done, I'll give you maybe say two, three minutes should be enough. Then I'll let you know to continue. Participant in the past, you could be shy. So on the car, you don't have to be shy. If you're stuck, raise your hand. There are a few of us around, we'll come to you and help you, okay? And the other thing is while we are doing this in other workshops, we also realized that participants when they try this out, they're not really unique in it. They're just using this time to write their code, write a test. Just one test passing and they're done. Now, the goal of this time is for you to try out the steps of TDD. If you skip all those steps and not ask a question and just get the result, that's 100% correct, I'm done. I think you'll be seeing the point of the workshop. So it's okay to struggle, it's okay to struggle, it's okay to ask questions, we are all around here to help, okay? Who's still more time to do those steps? Who is not finished yet? Raise your hand. Okay, one, two more minutes, okay? We're good? Yeah, okay. So I continue. So just some guidelines for the exercise. Try to push every, I would say, five, 10 minutes. Now that we can see the result on a dashboard directly. We have a bell over there, so I'm just gonna ring a bell as a reminder because sometimes when you're lucky to your code, you don't think about it. So the bell is for pushing your code. We have two comments for you. So NPM run tests to run the tests in the terminal, the console, and NPM run coverage will run the test coverage in your console. So you will see a nice table with a line, branch, and all the coverage possible there. Okay, so just before we start the exercise, reminder, so TDD, red, green, refactor. If you look at a cycle during the demo, it's very fast. So each cycle is maybe one, two minutes. So I don't write code during 10 minutes, then write a test during five minutes. So it should be very fast. So try to break it down to a very small step. So this is the point of TDD, and this is what's difficult, okay? As Ken said, it's okay to struggle. We're here to help. So this is the exercise. Forget about the timing. So the inputs, in this case, sentence. So she sells seashells by the seashore. It can be any sentence, not only this one. The output is an object, or you decide what you want, or a string, we let you decide. That will count the words. It's case insensitive. So in this case, every word appears once, except C, that appears two times, and one with the uppercase. But as it's case insensitive, we count it as two. As I say, this is an example. Every sentence should be working. Don't take it to account with characters like comma, or like exclamation mark, question mark, those kind of things, just space and characters, okay? Any questions for that? So good luck, and we're going around, and just raise your hand if you're stuck. Sorry? This one? I'm ending, that means we added them, but I think they haven't accepted the invitation. Oh, okay. Second thing is, maybe the bell is there, so I don't know that you told them every five minutes. Yes, I told them that. So just, I've been telling, so later I was telling me that some of you didn't accept the invitation from the GitHub, so maybe check your email, and you have to accept it to be added to the group. Can I turn it off during the exercise? Sorry. Can I turn it off during the exercise? Because now we're going around and to help them. I hope you discussed well of all the feedbacks. Now, if I can ask one representative of each table, you can just share with the others about your discussion, and if you have any questions, just please ask us, and we try to answer them. Can we have a mic? Where's the mic? Where's the microphone? Sorry? Oh, so who wants to start? Please don't be shy. OK. So it was more about breaking down the problem in small parts that you had the difficulties, right? OK. To address this, I would say the most difficult in TDD is to be able to see the problem, and breaking down is very incremental, a small step. So that's all the magic I would say in TDD, what takes time to get. So it's all about practice. Yeah. Next one. Back to training, the counter-object, and how do you find the back end that I had like in this model, right? That's its purpose, right? Yes. Where do you find the balance? OK, so that's a tricky question, I would say. But there's some kind of rule that says that every time you have like a condition that repeats three times, or you can see three tests that fulfill the same condition, then it's the right time to group them together and have some logic. So that's one of the rules. Now, sometimes you can take a bit of shortcuts. I would say if you see it's logic and, OK, that's obvious, then you can take shortcuts. But those are, I would say, the rules you can follow. You're welcome. Next one. Nothing of the larger model right now. In this case, I guess the first question is to use some sort of extension to start counting on the projects that it's hard to switch to a proposal that you just try to come and go in for the same situation. And also, the second part was that because we've written out a string, so if you think that you've written a string, if you are doing it correctly, then follow where you add a comma that you want, then you want to remove the last comma. So that part felt like when you jump from one word to more words, it felt like I was sending a lot of logic, too much logic, so to be honest, and I guess I'm still not too sure what's to make a step in the process. OK, that depends on how you approach it. It's about the small step you can take and the code, you only write the code when a test tells you to write it, basically. It is no other choice and it doesn't make sense. If you have to refactor everything, that's fine. But as long as you have the previous test that says, OK, that was the state and it has to be like that. So, yes? One thing I would like to say is just to add on to what Jeremy just said, I think one thing I would like to say is whenever you try to code, validate your assumptions. So if you think the problem is as such, validate what you think is correct before you want to implement it. That might help simplify your problem. For example, we spoke about commands, so you could just check whether that is something that is necessary and that might have sorted out They're going to demo later on the programming to resolve this in TDD. So maybe you help you show what a step they're taking. Yeah? OK. So, I should add, today is very basic, I would say, with the small functions in the real world when you have a production system, it's way more complex. But the idea is still to break down to very small functions that are testable. No matter what this function is, whether it's HTTP or any other protocol, then you can mock this part. The idea is to isolate your function and to simulate what's around your function. So then the idea is still valid for TDD. As long as you mock and you simulate what's around, then your function should still be tested in a TDD way. Usually you mock. If you do with actual data, you have to connect your HTTP and everything. This for me is more like an integration test. So you can still test after a while. But the idea of mock is that you control your environment. It's not open to every kind of data that can come in. I don't need data to answer your question. I mean, in a way, we write a test and we write an implementation. The cycle is very fast, right? And in the end of the day, when you have enough tests to finish, you run all the tests. It runs very fast. So the question in this case is since you have production data, if you're going to write a test, I don't take your test against production data, but if that's really the case, does it cost your test to run slow work if you're really with them? That would be the first consideration I think. If you run slow, you should look for ways to make it fast. How? One way is to do mocking. The other way is you can have a mock API and everything so you can do the best. And you take samples from production and get all the edge cases and care amounts. You put it in there. Then you test against that interface. Of course, the top option is to use a mocking framework into your unit test itself. Personally, I'm not a fan of using mocking frameworks. I would tend to go for the second approach. But sometimes, you really need a mocking framework. So both the side of the back and the first of all, where the community is supposed to help you to take through your design. Secondly, the test is run fast. Whenever approach is used to achieve these things and your test is not running fast, you need to take a strategy. Anybody else? No? Okay. I have a curious question. How many of you guys have one test and you have an implementation already? If you look at your unit test, you have one test. How many of you guys have two tests? Three tests. That's one person. One test. Six. Seven. Eight. Nine. More than nine. Okay. Remember, the goal here is not to save your more tests. The goal here is to give you the confidence when you write a code. That's the goal. So usually, before between people, some people may need more, some will need less. And then if you as a developer are still using a TED technique to write your code, you yourself need to feel comfortable with what you have. Because some of us may be a bit more scared. For example, what about this boundary case? What about this edge case? In order to give you confidence, you may want to write a test for that. But for some people, they may feel that actually a client operator can handle it so you do not get that additional test. So it varies and it comes with experience. So what I would say is, the longer you try it out, the more confident you are in taking small steps. That should help you engage right into the start. Okay. Okay, so now we're done with the TDD part. So I suggest we do a small break, about 10 minutes. And then we're going to start with the peer programming part of the workshop. So don't forget, there's some snacks over there, drinks. What time is it now? It's 36. So at 45. See you at 45. We start. So the second part of this workshop is about peer programming. And just do a quick sound check. The last table there, can you hear me? You can? Okay. Before I even dive into this topic, let me just say one thing to those who have voted the part where you say you hate it. This session is not to convince you to love it, but rather it's really to ask you questions about have you considered certain aspects of peer programming when you were doing it? Were those things present? Maybe because those things are not present. That's why it makes you uncomfortable. Maybe it's because of those. So try to consider. Put that into part of what you think about. I'm going to start with Ken back. As you guys probably know, when it comes to peer programming, when it comes to test-driven development, these are all extreme programming. They all come from extreme programming. And so this is another quote. He said this thing, if quote reviews are good, we will review quote all the time. And the thinking behind that is if if certain things are good, why are we not doing it all the time? One example is if testing is good, why are we not testing all the time? That is why it introduced test-driven development, test all the time. So now when we come to the topic of peer programming, if quote review is good, why are we not reviewing all the time? And that's where this practice comes from. I don't know how many of you guys every day when you wake up, you go to work, you look forward to review other people's quote. You look forward to approve a pull request. How many of you guys enjoy doing that? Okay, very nice. For the rest of us mortals, we probably don't like. And sometimes the problem is this. Somebody writes some quote, you have no clue of the context, and you just got a pull request, you look at the quote, and the best way to do it at that point in time is what you do. Syntax check. How much value is that? And if you're in a hurry, you check the syntax, nothing seems to be serious. All those now cases are handed, so you just accept that. But the thing about peer programming is it allows you to do quote review on the fly, and I'm going to explain it a bit more later. Now this is what peer programming is and what peer programming is not. I hope this session is just to clarify for you guys. This is quite a fair bit of misconception. Let's start with the left side, the white one. First of all, peer programming is not paying two persons to do the same thing. When a manager or someone outside will look at two programmers sitting together doing something, you may assume that they are doing that. But in reality, when it comes to programming, the fact that you type right is actually not what you do most of the time. So, peer programming is not paying two persons sitting on a keyboard just typing is not. It's about, on the right side, it's about investing in better software quality and design. I do notice even earlier on when we do your TDD, some of you guys already are collaborating, talking to each other already. Now, when you face such a simple problem in this workshop and you're able to collaborate, what more when it comes to writing production code? Why shouldn't we collaborate in that manner? Second, some people would think peer programming is only good for training. In other words, oh, a newbie just joined our company, let's pair. And once the newbie can fly, leave him and let him do his own stuff. But peer programming is also about complimenting each other's strength and knowledge. Like, today you may be working on this part of the system, the other person and other part. Then the next day when both of you come together you have knowledge about your entire system even more because two persons are working together. You compliment each other. Some people think that peer programming works well only for a small number of people. That may be something that instinctively we may think, especially those who haven't paired before, you may think that, wow, I don't like to be looking over my shoulder. But those who have tried peer programming surprisingly it works well for majority of people. I'm not saying for everyone for majority. I've seen some cases where it's just it's just not possible to pair program well with the person. But it works well for majority. I hope today over here is the majority part. Pair programming is not just code and syntax review by the partner. So you have two persons sitting, one person typing the stuff. The other person on the left just look at all the syntax and correcting all the syntax. If you did pair programming in the past and that is what you do just do syntax check I'm calling that suffering in silence because it's very boring just sit there and syntax check. But rather pair programming is a context rich review and collaborative design activity which also means that when someone choose to write code in a certain way since you are around you have the context on why that thing is being done that way. And if you feel otherwise immediately you are able to comment because you have a context. Unlike when you do a pull request you just review someone's code you may not have all the context. So this is why pair programming is also quite effective in a sense. Gives you context rich review. The last two things is that wow my team is doing pair programming. I don't like it because the moment I step in the office I must be pairing with someone else until the moment I leave the office or even cases like I just want to try out a certain things on the play of certain technology wow you mean I must pair with someone to do that. No, usually the recommendation is minimally you should pair on production code. In other words the code that you write they will end up being production systems. You should at least minimally pair on that. And the last thing is a normal individual time. It's similar to what I've just said. The moment you step in the office you must start pairing already. So even when I check my emails reply to other people I must pair as it. It doesn't mean that. You can consider this thing called call pairing hours. Your team can agree to say that when we do pairing a production code we can start pairing from let's say 10 a.m. to 12. Then take a lunch break then maybe 3 to 5. The rest of the time you can do the rest of the things that you need to do. I'm quite sure none of us here have this luxury of going to the office and just start coding right. There's always meetings and all these other things. But if you have a call pairing hours you could focus on writing the code. The rest of the time you can do the other things that's required of you. Terminology I think it's important to clarify the terminology because going forward I'm going to keep using these words. What is a driver? A driver in pair programming is a person who's typing on the keyboard or holding onto the mouse. That is a driver. You are the one who types. The person sitting next to you in the past is called partner. That's your partner. It's nothing wrong to call a partner. But I've also noticed that the terminology navigator comes out in play. So if you're getting someone to sit next to you and pair with you at the same time try to think about what other scenarios that you may need to cover you need to handle in your code. So the partner or the navigator works with the driver together. I'll be using these terms interchangeably as we go along. Right. So at this point we're going to do a pair programming demo. In fact I'm actually quite happy that most of you are still around because some people say, I don't want to leave already. But at least you can try it out. For the demo, before I demo that I need you to find someone to pair with because you're going to try that out as well. First introduce your name and what is your favorite programming language? Find a partner first. I'll give you one minute shouldn't be hard to find. Okay. Start looking for a partner. We have people who's ready to pair with you. Elnaden, Anu, Amu he won't be available yet. Okay. Now the next thing is the next thing is between the two of you decide whose laptop will be used. Okay. Decide whose laptop will be used because you're using one laptop. As a pair you're using only one laptop. Okay. I'm going to move on now. Right. The reason why I ask you guys to pair up now is because later on when you actually do the pairing to write a program you have to watch out for this thing. And this is my guide. A hitchhiker's guide on how not to pair a program. Not to pair a program. Okay. And in order to demonstrate this I invite my camel and Kevin. What they're going to do is they will show you a scenario you have to observe the scenario after that you tell me which one from one to five which one of it that they are doing. Okay. What is the dysfunction that they are showing over there? Clear. So I'm going to ask them to start first. Alright. Okay. Okay. Okay. Okay. Stop. Alright. Which one is it? Second one. Quiet Quincy and Disengaged Dan. Which one is the Quiet Quincy and which one is Disengaged Dan? Huh? Yeah. You mean Amu is quiet? Okay. Yeah. What's happening is Kevin wasn't talking very much when he called. And Amu did try to engage but in the end he gave up. That's why he pulled out his handphone and started surfing. Okay. Before I even comment on that let's go on to the second scenario. Okay. Alright. Okay. Guys, ready? What do you think we should extract the right way? No, but I think that the test that we wrote is wrong. I think I know what I'm talking about. I think it's the right way. But I thought where that time we should go. Yeah. Okay. Stop. Which one is it? Sorry. Someone say hogging? Five. Hasty Hansen? No. That's not. One. Righteous Ron. Is it right? Yeah. Righteous Ron tends to be the kind of person when you quote, you always think he knows the answer. It can happen but in pair programming you have to be open to listen to other suggestions and that's from a perspective of the driver the person who types. Now sometimes it's the person, the navigator who thinks or the partner who thinks he or she is the right one. No, you're doing this wrong. You're doing this wrong. Pair programming is a collaborative work so both sides needs to learn to collaborate in that sense. What's the scenario? Okay, I'm going to hear a question from the driver name should we be closed because the code is okay, stop. What is this? What is for? Dirty Harry. Is it right? Yes. Okay, not a segment. I think in terms of one way our tidiness or how clean that impacts Pair programming a lot I used to pair with an ex colleague in the past before you start pairing you always think an alcohol wipe to wipe the keyboard and to wipe the mouse then only we start pairing. I was laughing at him and saying why are you doing all these things? We are clean. Then he tries to prove to me that it's not clean. How? By taking a keyboard flipping it upside down patting and all the crumbs and the keyboard comes out. Now, and sometimes dirty Harry can occur where you eat oily food, right? Now Pair programming doesn't mean you cannot eat food while someone code, right? Then with your hands oily you start to grab the keyboard and start typing. Then you give back to your partner. This kind of things hygiene we have to watch out for, right? Okay, next one. Okay, can you do what you're doing here? Yeah, just kidding a minute. I'm not sure if I should do something. Wait a second. Okay, stop, stop. That's a bit overacting but okay, what is it? Three or five? Which one is it? It's Hogging Henry. Hogging Henry. Yeah, when we get we have this thing called a flow as developers we get into the flow and sometimes we get into a flow we just don't want people to disturb. What would be helpful in that case is to have a certain comment understanding before you start so that if you're in a flow let your partner to do it or if you feel not confident at least talk about it beforehand, alright? One last thing. No price for guessing then. Okay, stop. That is Hasty Hansen. Yes. Now there's one thing in psychology, in programming psychology is you need to understand the person who is typing will not always be the fastest to spot things. The person who is watching usually spots things faster. For example if you're typing and you try to click on the menu file open. Let's take the example. Your pair will catch something which is faster than you do. Sometimes you just couldn't see it. There's just psychology. It goes with this thing. If you write a code you open your bracket close your bracket and you miss it usually your pair will spot faster. Now when it comes to pairing you have to be patient. Let the driver take his or her time to finish what is finished until you realize he or she really forgot. Then you're going to make a note of that. Or if you see a driver is struggling and you know that it's because of the syntax error then you can point it out. These are the 5 dysfunctions on how not to program. Thanks guys. Deserves a clap. So from that end I'd like to move now into how then should I approach pair programming. This is what I would use golden rule to pair programming. It simply is do unto others what you want to do unto you. Like treat others like how you want to treat you. And this is not a very difficult skill. Some people call it kindergarten skills. Since young we are taught to do that. So some suggestions. This is an incomplete guide. This is an incomplete guide because you may have your own ways. First one is use we when expressing something that may not be favorable. You may be coding and you find your pair is coding towards a wrong direction. When it's going through a wrong direction you don't start to say something like that's a stupid way of going. You're going the wrong way. Rather than that say I think we are going the wrong way. That brings in the team spirit. This is a simple phrasing but it does help. Second point when you're going that stuff for you. Your pair may be typing something and you couldn't follow. So what you would want to do is say I'm sorry I cannot follow what you're doing can you explain to me. The third one is the navigator can offer to drive when the driver is stuck or when unable to express an idea verbally. So you may be pairing a partner and he or she is typing. Halfway through you realize he or she is stuck and you have an idea. Why not offer to take over the keyboard and just say let me show you what I have in mind or you may not check. Are you stuck? Can I help? So you just take over and start typing. That's how you swap the roles within the pair really quickly. Point four is drivers consider vocalizing your thoughts whenever possible. Remember just now there was one point where Kevin is just typing saying anything. I don't know how many of us here have the ability to read minds. Now because of that we don't have that gift. We need to help our pair to know where we are going. So if you try to think about vocalizing what you're doing and what you're thinking. For men typically you can get a bit difficult because we cannot multitask. It takes time to train yourself to do that. I remember if you if you read the book Pragmatic Programmer anyone who read that before Pragmatic Programmer So there's this part where they talk about rubber ducking. Rubber ducking is a technique where if you're stuck imagine you are writing your code and you're speaking to a rubber duck just vocalize what you're doing that sometimes helps you to get unstuck and when you're vocalizing with your pair that can be helpful as well. Right? So later on when you try the pair programming try this consider vocalizing your thoughts and see how it feels if you're not used to that. Point number 5 Give permissions explicitly and upfront especially if you're pairing with someone new. I notice among us there are some of us are people who know each other so that can be easy but if you're pairing with someone new that person may not know how you work and you don't know how the person work. You can consider telling upfront what you're comfortable with what you're not comfortable with. I remember when I first pad I was telling my partner stop me if I'm too fast I was full of ego I thought I could type very fast that my partner cannot follow. But most of the time you told me you're too slow. Okay, fair enough. But it's things like this that's helpful you know at least you know you give your partner permission when you're being stuck can you just jump in feel free to just jump in that will set up a good context for you to start pair programming. Point number 6 Navigators watch your drivers back by tracking reminding things. Now this is really useful especially if you do test driven development. Your partner is thinking about test case writing the code and when you may realize what about this edge case that you need to handle. Now instead of disturbing the driver stop I have something to discuss with you and your driver is in the flow you just jot down that the thing you need if you feel that needs to be addressed and when the driver has reached a logical point just talk to the driver I think we need to handle this special scenario. That's one of the things that I find it very helpful in the past when I pair with someone else. Point 7 Navigators be patient and this comes to Hasty Hansen the person who is typing will always be the fastest. The next one is lose the ego and put on humility this especially if you are not used to pair programming or your parent is someone you are not familiar with all of us fear that we are being judged this person looking through my shoulder I wonder if I am good enough we always fear that but if you always have that thinking in mind it's going to be very hard to pair you have to learn to let go of your ego and put on humility all of us make mistakes so it's okay to make mistakes last two things first take care of your person hygiene dirty Harry so not going to comment more and point number 10 is swap pairs often at logical stopping point one of the reason why we do pair programming is because of knowledge spreading you work on a module that person will also get the knowledge how many of you guys here do scrum okay everybody do scrum I assume your sprint length is about 2 weeks, 3 weeks 4 weeks 4 weeks is the maximum already if more than that you are not doing scrum if you pair together and you work through the entire sprint you kind of lose the benefit of pair programming because you are not sharing knowledge enough within the sprint you are creating a silo within the pair for a sprint so when you come to pair programming you usually want to split pairs within the sprint itself it's better if you there are options for doing that you can split at the point after you do a check in you split with someone else or you can finish a story for example then you swap pairs I think this is one of the most common people like to pair which are so much more swap you must actually do that swapping now when it comes to 2 persons sitting together when you look at a person you have just decided to pair with how do you do the pairing earlier I was just talking about attitudes and behaviors now the mechanics there are generally 3 options I know there are variations but I will just highlight 3 the first one is time box time box means when 2 persons come together for x amount of minutes when the time finish you swap the role so the partner now becomes the one who drives rest the other one will just be the partner that's time box it's up to you to figure out what works for you in terms of time box some people try the Pomodoro technique there are variations to that the second one is called fluid fluid is when 2 persons work together you can just swap at any point in time for example if you are stuck the person just take over and continue or if you feel that you have better idea just take over and continue and just keep swapping there's no definite time to swap but it's fluid third one is a ping pong technique where 1 person will write a test case then you pass over to your partner to write the code that means your partner becomes a driver now the code to pass the test case and this works well if you do TDD you write a test then your partner write the code later on I will demo I will demo for you the ping pong method when I pair with Amu and the last one is really variations of the above you can always change and between different partners some would prefer different things try it for yourself what works so when I'm sitting with Amu later to avoid this demo as a spectator spot I want you to notice something because there are some things in your interaction that you need to pick up and we'll do a debrief after that what is it that you pick up so what do you notice or pick up from this demo so I want to no not this one so I'm just going to do a demo now I invite Amu come sit with me at least one you say hello to me I'm just going to adjust the mic a bit guys can you hear me can you at least see our face if not then we may need to turn on the lights they can't see the screen they can't see the screen good can you see this it's okay we are going to use ping pong for the pairing session I suggest that are you okay anytime if you want to take over the machine feel free to so let me just give you a debrief yesterday Kevin and myself we are pairing the word counting exercise so we are writing test I got some test cases passing for the simplest case for example a single word but then 6 o'clock came and we just decided to go home so I just want to pick it up from here today and since you are available pair with me so since we are doing ping pong I start what is the current state of the test case are they all passing I never thought of that let's see if we are on a stable ground so let's just run the test one of the test is failing we are missing some implementation probably so this is a case where I have two sentences repeated twice I am supposed to get two that's where I failed the test case yesterday where I went home are you confident to try now or you want me to write over to the code file so we are basically missing the scenario where we need to have two words a possible solution that I can think of is since we are doing it the 3D way maybe I can implement this fake it till you make it so I will probably select I will check the sentence to be equal to the third word and if that is the case I shall return the frequency for what does that make sense let's see if the test case pass that's nice shall I introduce the third test case so now that we have these two words working I am thinking of introducing a different word that should help us to take a case where our expected result can have more than one word count let me show you what I have in mind so what I was thinking of is just to a sentence with different word and a word repeated twice in that case it should return a count of 3 and count of 1 for the non-repeated word is that okay okay I will wait for you to write the sentence maybe so let me just add one more maybe called another word okay I think we would probably be expecting the count of 2 instead of count of 3 ah yeah yeah that looks more reasonable yep so in case of this expectation I would want to have another and one does that look good? so let's run the test make sure we are still okay with that nice is it failing based on what I expect yeah so it's expecting two words but we only have a single word yep okay so now what we need to check is because we have different words I could fake it but the solution is kind of obvious so I would rather want to break down the sentence into different words okay and send out the frequencies from there so loop through the array of words that I receive passing the frequency but I think it will be some sort of refactoring so actually I'm not comfortable running this test yet could I uncomment this make the code change and come back to it so I would comment this out and what I'm trying to do here is I find out what I have in my sentence you would want to split the sentence right yes sorry so sentence so I'll split it with the space yeah so I have the words and then I will go through each word yep and now I want to check whether this word is present inside no it should be an accumulator accumulator of some sort collector yeah we need something to collect does it not check does that make sense does word accumulator make sense or would you prefer something else yeah it makes sense to me accumulator so this accumulator will basically store the frequency of each different kind of word so now what I'm trying to check is let's clean this up if word is already present is to be present in sorry here on line 5 the keys it shouldn't be sentence right it should be accumulator right so if I find that object what I want to do is increment the frequency for that specific object so accumulator word bus bus and if not I wish to initialize it is that correct I don't think it's correct but you can run a test case and see how it looks okay what is that yeah because this needs to be a function I see right so word should be pull 2 let me rename it yeah it's not clear so it's clearer because we are looking at keys so let's call this key yep so I expect the word to be equal okay alright test pass okay so let's comment our do you want to refactor first because I felt that the code just now especially line 14 the sentence word word I don't think we need that it could be the cause of it passing yeah should I remove this let's return right so that's the final result that we have yep it fails yeah sorry what is wrong so let me show you so what I'm thinking of is I wonder is because of the pass pass let's try this nope fails again I think what we are expecting is there is probably an issue with the result that we have actually this should not be 0 right oh yeah it should be 1 alright it should be 1 because when the object isn't present but you already iterating through it so I think the plus plus should be fine too let's do that open passes okay so what's that yep let's yeah let's try that oh pass is it the real full set looks like it okay yeah alright do you think it's time to check in looks like we have reached a logical point yeah sure I think I'm good with it I wouldn't want to refactor this at this point in time okay do you think we need to have another test case or is that sufficient coverage for now I think it's fine for now okay cool thank you thank you let's take a break okay so what do you guys observe what happened or sleep already the code is so boring that it's slept okay sorry let me change the mic because this is too much feedback while I change the mic can you guys start thinking what do you notice about my interaction with abo or his interaction with me yeah okay someone asked me a lot of questions like shall we do this are you okay to do this so that is his style when I pair with someone else it could be different but yes that's a useful thing to ask sometimes just to check what else do you notice I can get you sorry when you made a mistake you didn't say it straight away all the time you made sure you waited until he was like finished with everything yeah we jumped too fast to someone's mistake because the person especially the driver he or she may realize it by him or herself later so don't you jump so fast what is this agreement that we started with we come together what was the agreement that we talked about yeah so we agree on how we're going to approach the pairing session okay anything else you want to raise that I miss in our pairing no we're good yeah so we actually check with each other on whether we are done with the test and this is the advantage of pairing as compared to doing TDD alone when you do TDD you don't know whether it's time to stop or not but when you are paired with you both of you feels that you it's a good time to pair then that's a really good feedback to get it's a good feedback to know when to stop and he also asked me about the renaming of a variable should it be an accumulator when we pair sorry when we work alone sometimes we come up with some variables that we think is clear to the whole world sometimes it's not having a pair with you to check that if it's clear for two persons chances are it will be clear for some other people as well these are all the advantages that comes as you work together on that okay so this that's about a debrief for the demo unless you have any other questions that you want to raise I have a point to ask basically when I reached out to Kian to know whether we have refactored enough if I was just working with my own I might have gone into a multiple alteration of refactoring my desk case, my code and I might have wasted a lot of unnecessary time or might have added extra code but because I had somebody who was helping me review as well so we kind of concluded together that that much of refactoring is sufficient it saves time eventually prevents unnecessary refactoring so pair programming is not silver bullet neither is TDD it doesn't mean when someone pair you get super results but if two persons pair you probably get better result than one person working alone that's what we are saying now if both of us are total newbies to JavaScript we don't know much about it probably the quality of output will not be as good as it can be but that's okay because at least it's better than one of us working alone like for example he may be struggling with putting the function into the find he may be doing so many things that takes up time just to find out whereas I can provide the information and say this is the part where we miss out now we are coming back to the pair programming exercise I hope you have your pair already the first thing I need you to do you can use the same code that you used earlier for TDD or you can pull from the same code base again except for this time now you do not need to check in your code you do not need to push your code with your pair first decide which approach you are going to do ping pong, time box or fluid approach decide on that then secondly after that you will be working on an exercise make sure you use the TDD approach for that and what exercise is this 99 bottles of beer who knows this song alright you guys can sing the way we are going to do this exercise is you need to write a program and this program when run is going to output these lyrics these are actually a set of lyrics the song starts with the top it says 99 bottles of beer on the wall 99 bottles of beer take one down pass it around 98 bottles of beer on the wall and the lyrics continue by reducing by 1 1 bottle of beer reduced second one is 98 when you see all the 3 points here it simply means it decrements from 98 97 96 so on and so forth until 2 bottles of beer until 2 bottles of beer and when it comes to 2 bottles of beer you have to notice something start to change the word bottle is singular now as compared to everything before it plural and when it comes to 1 bottle of beer now this word becomes singular the one on top is plural and this change and this part change as well of course you have the last one which is no more which changes to no more this whole sentence change and this becomes plural again clear? your mission should you choose to accept it is to write a code that dumps all these text out you can choose to hard code all the way from 99 to no more but I don't think your pair will allow you to do that alright? show the pairing right now try to do pairing and also try to do TDD style for this I'll give you 15 minutes to do that I'll do a time check with you later there's no need to push your code into git anymore 15 minutes let's stop here question how many of you guys are relieved that the pairing session is over laughing means you're relieved one comment before we do the debrief I notice the way you guys do pairing some of you guys who have neck pain tomorrow or spine pain tomorrow because you're in an awkward position in fact I think sometimes a driver doesn't know it the driver is so comfortable but a navigator is just trying to find a way to see and for some of you guys who are so kind where you share your laptop the navigator can see right but the driver is outward positioned so this is one of the things that we need to take note about when we do pair programming is the setup of your laptop or your tables and all those things sometimes you don't like it because it just makes it awkward now there are some plugins for editors where you can have two laptops connected together you can see the code comfortably in front of your own laptop while the other person when you make changes you can see it reflected I think Visual Studio or Visual Code has it IntelliJ should have it as well the other option is to have your laptop plug in to a common monitor then you have plug in an external keyboard to the laptop so both persons you have two sets of keyboard two sets of mouse but a common monitor so these are things you need to think about when you do pairing it's good to see you guys at least try it out but I don't think it's sustainable as per what it is after maybe one or two hours you'll be so tired now the other question I have is actually I'm getting a debrief now mentally wise do you find it taxing do you find it to be more tiring as compared to doing alone how many of you guys feel it's more tiring when you do pairing okay who finds it less tiring okay just to be clear it's a binary option tiring or less tiring for those who didn't answer I don't know what is that but it's true pair programming can be tiring that's why when you do pairing it's always good to take a break it's very tiring but I remember the first time I did pairing it was about a whole six hours straight when I first joined the company I did it I was totally tired at the end of the day alright now is your turn to tell me what are some of the challenges that you face where you try doing pairing just now apart from the things I mentioned okay Kevin has a mic so maybe you can just share what are your challenges just raise it okay true what I did was actually creating a bit of havoc for you because you're not at a logical point when you split pair so you have to rethink the context and you're actually working on the same thing except in a different way that's why I was suggesting look for a logical point to split pair and not do what I did just now the reason why I do it is because I want to create a bit of chaos second is for you guys to feel how does it feel like when you work with someone else what other feedback do you have this is the big bug and when I switch to other computers the thing applies to actually it was pairing someone who only used big apps to do pairing on the other computer and on the hand he or she can pair with the other computer it's kind of difficult because they can kind of train you to use it thank you very much and that is a very common thing in fact once I paired with a guy whose keyboard has no no markings it's all black I don't know how to code so what you shared is true because I think as developers when we code alone we have our own customized way of doing it we like a certain editors in fact one thing other thing is we like to code our own way brackets whether you start in a new line or not the spacing all these things will come in the picture now pair programming in extreme programming context team effort is a team thing which also means that instead of just between two developers agreeing in fact your whole team needs to agree what is your coding standard what is your editor they want to use how is supposed to be set up these are at least the minimal things that you need to have in order to be comfortable the other way is I've seen if I'm correct there's some plugins where both your machines can connect together but you can keep your own customized way of your editor so whatever the other guy change right using the laptop you will be able to see yet you are not constrained by that I haven't tried myself but I've seen it I think it's not a bad idea to try that yeah okay I mentioned what else do you guys have to feedback for that on your pairing experience how do you feel when you have to switch pair of course if your pair isn't a good pair you'll be happy or you switch pair right but how do you feel when you have someone totally new coming no reaction okay okay I'm going to skip that then male-female pairing how do you guys feel it's okay these are things these are real real scenarios you will face so let's talk about it how does it feel do you feel it's an issue or non-issue I'm looking at you guys I can see the females and males here what do you guys feel no issue okay that that table there okay that that table okay in front of everybody see no issue inside a lot of problem I'm kidding that is a very common common question how how should we pair if it's a different gender but it's not just within this room there's no issue there's a book called pair programming illuminated Laurie Williams generally throughout the studies of studying people doing pair programming it's really not an issue the only thing you want to be careful of is the space between two persons some are more comfortable together some may not be that comfortable just be aware of that I think it happens between guys as well right sometimes brush another guy's hand if they feel it happens okay just be aware of this kind of things what if two hands touch at the same time sometimes got electricity sometimes don't have but these are things we have to be aware of maybe one more thing anything else any other feedback for those who try different methods of pairing of swapping time based fluid and I think you guys are doing time based and ping pong how do you feel about different methods I mean the time based one was really fun time based one was really fun it's just not working not working at all not sure okay question do you think would you think that method would be sustainable over time let's say you do this for 8 hours the whole day by swapping so you may want to be aware of the things that you try it may not be sustainable just switch to some other way how long do you choose between you swap 2 minutes wow okay you know this thing about pair programming very early on when XP started usually people would swap around maybe 10 minutes this is more extreme than extreme yeah okay fair enough if it works for you I think it's fine so this is really debrief so at this point I think we have 15 minutes left it's time to close thank you for participating I'm quite sure I hope you guys enjoyed in fact I noticed the level of the bus level between the first time when you do TDD as compared to the second time the second time seems to be more alive more interesting for those who didn't like pair programming I hope today at least would give you some idea on how to make it better to make it a more enjoyable experience for you just to recap it's almost 3 and a half hours in this session but if we don't know what's the benefit why we're doing it, I think we kind of missed the point so I'd like to come back here to talk about what's the benefit of doing test driven development and pair programming at the same time these are just 4 points the first one is increased software design and quality and the reason if you do TDD it helps you to think through your software your writing of course it's going to increase your quality because your test covers your code to make sure it works and the consequences of that is you have lower defects second point, you have good knowledge spread when it comes to pair programming since most people swap you have a good knowledge about the systems that's being built now what about test driven development how does that help us with good knowledge spread you're waiting for an answer now the way good knowledge spread is the test Kevin raised that earlier you look at the test, you know what is it doing you know how the code is supposed to behave that helps to spread the knowledge as well if you're code based but no test it's hard to get the knowledge because all the logic is you have to spend a lot of time trying to figure that out now because there's a good knowledge spread you reduce single person dependency problems the kind of problem where you work with a team you work alone and you want to go for two weeks holiday in an island and your team expects you to be on call because they may call you and ask you what the code is doing having doing TDD and pair programming it's okay for someone not to be around because someone else will know what has been done so that is reduce single person dependency the third one is it increases productivity overall TDD January will increase productivity pairing it takes some time until both pairs you get into a flow into a state you may sometimes find pairs argue over things, takes forever and never get resolved this person thinks this design is good the other person thinks his design is good so how do you resolve those kind of problem one way is usually bring it to the team and discuss with your team what you're thinking of and it's actually a useful way to try to resolve issues now because it increases productivity the team would move faster and the last point is it builds courage in teams what do I mean by that if you change a piece of code that doesn't have tests you'll be scared if you're not scared I salute you personally I'll be scared because I do not know if I break anything or not but if I know this piece of code has a test coverage by adding functionality and the test doesn't fail it gives me courage so that's how TDD helps the other thing about building courage when it comes to pair programming is a case where if you need to face a problem alone as compared to having someone to face it together with you that should help you in having more courage to face it I remember there was a many years back I was sparing someone checking the code 6 o'clock went home so happy midnight got a call, got production issue so this shows TDD and PAIR programming doesn't solve all your problems but the fact that at midnight 12 am I have to go back to office I know my PAIR would go with me and we stay until 4 am that actually increases my courage in facing a midnight issue to be able to solve that and because it builds courage in teams it helps to improve the team morale you finally feel that you're working as a team and you can go forward together these are the few points that I personally have felt after doing TDD and doing PAIR programming anything that you want to clarify based on these points anything you want to get back to me on you feel that maybe it wouldn't work no? yep in my opinion the last point is tricky because the courage can be falsely because you have to trust that this test which was rewritten was good and it really test the functionality so I think you should check tests before you have the courage to say ok I can add functionalities, methods and so on and so on yes I think Kevin didn't mention one thing is you can write a test that has 100% code coverage that doesn't test anything I don't know if you guys have seen it before if you don't believe just write a unit test write a code but don't assert anything in your unit test you still get 100% coverage that's not TDD first of all and yes so in terms of whether you think the code will work or not it really depends on how well you know the people around you and if you compare with the person before in terms of how you feel about the quality that's being done ok is there anything you want to add on this last point I think you summarized it quite well as you mentioned test as you wrote on the code so because you have test that you have to write the code ok it means green test are very good so you have to read them as well and refactor them another thing maybe so at the beginning it might be difficult because you have to get used to it with the whole team if you do that on the long run you will see a lot of benefits so don't try to base control on yourself if you are doing anything so try this as a team that's all I can add thank you I miss out on that so it's useful so before we leave let me close a couple of announcements first of all if you see this thing, these are meant for you gifts not gold, pen and this one other than that this thing called a sharpie is not meant for you please don't take it with you and these are not free as well so don't take it with you the other thing is when you leave we would really appreciate your feedback about the session and what this means is you can write your feedback one feedback per post-it whether it's good or bad feel free to just whack after you return it, when you leave the room post it behind the flip chart there if you see it, the one at Chris is pointing to they will be useful for us to know how to improve the session that's the first thing second thing is when you leave if you are interested to be notified by Palo about any events or training events feel free to drop your name card at the bowl behind at the table there next to the alcohol wipes Chris is bringing it up again with that I think we are done close enough so thank you very much for your participation we are supposed to take we are supposed to take a group photo so we can stand up and come here we can stand up and come here we are going to take a picture