Jeff Terrell: Okay. Getting started now. Thank you. Yeah, this is late marine from Bath National Park and Canada. I love it. I've been there a few years ago.
Jeff Terrell: This is, I guess, our winter time is from when this picture was taken when I was there in the summer. Anyway, so yeah I'm trying something new today.
Jeff Terrell: I'm actually trying to use OBS to do my my lectures and stuff so
Jeff Terrell: Let me see here.
Jeff Terrell: Okay, so I'm a little bit. Clumsy and awkward here, but we're going to try to do this.
Jeff Terrell: Also this computer is sometimes prone to crash. I've got my fingers crossed that won't happen while I'm actually lecturing. If it does, then it might take me a minute or two to join the meeting on my other computer, but we'll hope that doesn't happen.
Jeff Terrell: Okay.
Jeff Terrell: So, yeah. Today we're going to talk about agility pick up where we left off. But first, some announcements that was Paranoid Android second try
Jeff Terrell: By Radiohead. I think this is the best example I can think of an agile band. You're always reinventing their style.
Jeff Terrell: Got all the way through that time, we're running a little bit late today, but that's okay. I think we have a little bit less content, as you may have seen from PR to them will be using sekai for the quiz today.
Jeff Terrell: So we were going to use open class today I but some of you said you're having difficulty getting signed up.
Jeff Terrell: And so I decided just to go with
Jeff Terrell: sekai just go with what we know.
Jeff Terrell: Is some of you. Noted, noted that the confirmation email was in junk and he'll mail or maybe it was in your spam folder or something like that. So,
Jeff Terrell: I'm hoping all the emails were actually sent, but maybe just some of them didn't hit your actual inbox to me had to go digging through your junk folder to get them. I don't know.
Jeff Terrell: We will worry about that more later, but today, just because there was some doubt as to whether everybody would actually be able to join Open Class I went ahead with sekai
Jeff Terrell: And Andy agreed open source is amazing OBS Studio is all open source and it's a nice piece of software.
Jeff Terrell: I've heard some reports from mentors that some of you seem to be fairly stressed in your mentor meetings this week.
Jeff Terrell: I wanted to remind you if you're if you're feeling stressed, especially if you're losing sleep over this class or anything else. Consider seeking help caps is available to you even remotely. There are other ways to get help, but
Jeff Terrell: I'm sorry if you're feeling stressed. I hope I'm not contributing to it too much. Although I guess some amount of work is necessary to actually learn things but
Jeff Terrell: But yeah get get help if you need help.
Jeff Terrell: Okay, so remember that assignment nine is gonna, we're actually gonna do that next lecture. So that would be Monday. Monday and Wednesday of next week. And so I wanted to spend a couple minutes.
Jeff Terrell: Talking about what to expect for Monday, so that we can really hit the ground running when Monday comes
Jeff Terrell: I changed the assignment to be six minutes long, not nine minutes long. I got to looking at it and I realized
Jeff Terrell: The nine minutes was when I had a lot fewer teams last semester or last year when I taught this course and this time around. We're going to need to pack more presentations in our
Jeff Terrell: Total time. I guess we have 75 minutes so you have a max of six minutes to do your presentation. I think this will actually be good for you.
Jeff Terrell: Are helpful. I hope so that you have less material or less space to fill and you're always welcome to stop early. That's never a problem.
Jeff Terrell: So long as you cover all that you're supposed to cover, but just please try to make sure that you're not going to go over six minutes I'd recommend rehearsing to try to get the timing down
Jeff Terrell: Make sure all your teammates have their timing down to
Jeff Terrell: Note that all Members must present. This is true of all of the presentations that will do in class. This year, including the tech talk in the final presentation as well.
Jeff Terrell: And please when class starts. Please join on time and be ready to share your screen. If you're called on basically what's going to happen is I'm going to randomly pick
Jeff Terrell: Who goes next each time. So one at the very beginning of class say okay team or whatever it is.
Jeff Terrell: Let's go and it'll be if you're that team. You'll have to share your screen and get going. So please be ready. Have your presentation pulled up and ready to go.
Jeff Terrell: And your screen ready to share coordinate with your teammates to figure out who's actually sharing your screen and that kind of thing. But yeah, please try to be ready to go. Monday when class starts so that we have a minimum amount of times and on the setup and technical issues.
Jeff Terrell: If you have any conflicts with that or logistical difficulties with actually making it on time to class or making it in person to class, not in person. But, you know, making it synchronously to our class meeting.
Jeff Terrell: Please let me know. I'll do my best to work around any sort of significant issues that come up. I want to be understanding, but also, you know, if you can make it. Please do if other things need to move around.
Jeff Terrell: Please, please move things around. If you can, so that we can all present I do need everybody to present that either Monday or Wednesday.
Jeff Terrell: If that's a completed possibility for some reason, just let me know. We can figure it out. That's, um, but I am hoping that everybody can be ready to present on Monday.
Jeff Terrell: Okay, I've been getting taking some polls and they've been actually really helpful for me to just take a pulse on the class. I thought it would be cool to see
Jeff Terrell: For all of you to see what the results of the polls were. I don't know. Actually, I'm assuming they got can't see the results from poles and pull everywhere. But if that's not true. Let me know. I'd be interested to know
Jeff Terrell: But yeah, let me share some of these. So these are all the polls from from yesterday, no yes to lecture on Monday.
Jeff Terrell: So right, I asked how helpful of the assignments been to structure your team's efforts and I was really encouraged to see this.
Jeff Terrell: Very helpful and helpful were by far, the two most common responses somewhat helpful and then just maybe 2% maybe maybe one person said not very helpful. So sorry if that's you.
Jeff Terrell: And some of you said somewhat helpful. But yeah, I guess that's better than nothing. So, but overall I thought this was really positive and I'm glad to know that the assignments that I picked for you have been helpful. So I would consider that a success.
Jeff Terrell: If you could have started coding right away and didn't have to do any of the assignments. Do you think it'd be farther along
Jeff Terrell: Maybe approximately even split between yes and no. Pretty decent approximation of a bell curve here. So that's kind of interesting.
Jeff Terrell: I guess I'm not concluding anything in particular from this, except that some of you think you would be farther along and some wouldnt and some probably don't know so
Jeff Terrell: I guess that is what it is. All right. How's the workload been so far, relative to what you'd expect for for our class again pretty good bell curve going on here. So some of you, you're saying it was this is significantly more work than you expected.
Jeff Terrell: Here we go with myself out of the way.
Jeff Terrell: Significantly more work than, than you expected, but overall, I'd say it looks like we're about on target with what people expect in general. So that's kind of cool.
Jeff Terrell: And how nervous are you about the walking skeleton at this point. All right. Some of you a good good portion, one out of five. You are quite nervous.
Jeff Terrell: And many of you. Most of you are either nervous or quite nervous and some of you have a little bit less nerves, but only about one attendee, you are not nervous about the walking skeleton. So this is about what I would expect to be honest, and I know it's a painful assignment, and I'm sorry.
Jeff Terrell: But this, we're basically shifting the pain up from the end of the semester to now this coming week and maybe this weekend as you work on the walking skeleton. This is all stuff. This is all pain that is going to
Jeff Terrell: That you're not going to feel later that you would have otherwise. So keep that in mind. You know, this deadline might be unpleasant, but it is intended to serve you in the long run.
Jeff Terrell: So anyway, I'm sorry that you're nervous or maybe that this is painful, but hopefully by the end of the semester. You'll, you'll think that this was worth it.
Jeff Terrell: I remember. Maybe I'll do a pull them to to see if you actually do you think it was worth it. After all,
Jeff Terrell: Okay, any questions so far about midterm presentations. I'm assuming again that you'll interrupt me in the chat. If you have questions or anything.
Jeff Terrell: Be any questions so far.
Jeff Terrell: Okay.
Jeff Terrell: All right, well let's let's get moving here. So today we're going to talk about, we're going to finish up the discussion of an XP extreme programming and talk about XP practices.
Jeff Terrell: I'm not going to talk about all of them. I originally had all of them in the slides and I realized like, I just don't think all of them are that important. So I don't want to
Jeff Terrell: Dilute the discussion of XP by talking about things that I think are less important, and that honestly I don't relate to as well or don't have as much experience with
Jeff Terrell: So I'm just going to pick a few of those that I think are pretty relevant and important to know and I'm going to augment that with a few other agile practices. That's a pretty common in in projects that I think work well and serve you well.
Jeff Terrell: And then we'll talk about combine and Scrum, which are two popular things happening and agile software methodologies. So we'll just kind of briefly talk about those things. But I'll give you at least a sketch of what they are.
Jeff Terrell: So let's talk about XP practices.
Jeff Terrell: Okay, so this is kind of a set of 12 XP practices. It turns out they're broken up into groups of
Jeff Terrell: There's four different groups and yeah that can be kind of interesting. I'm sure the book by Kent back talks more about all of these different categories and what they mean, but
Jeff Terrell: I don't, I'm not going to go over this entire you know everything on the slide, I'm just going to pick on the ones that I've boldfaced here.
Jeff Terrell: So let me start with pair programming.
Jeff Terrell: All right, what is pair programming pair programming is two people working as a single unit to write code.
Jeff Terrell: You can do pair programming with more than two people. I suppose that wouldn't technically be a pair programming, maybe that would be like mob programming or group programming or something like that, but
Jeff Terrell: Pair Programming tends to be with two people. That's kind of the most efficient use
Jeff Terrell: And this is not two people with two computers. This is two people with one computer
Jeff Terrell: So there's only one person at the keyboard at a given time both people can see the screen, but only one is driving
Jeff Terrell: So there's a driver role is actually using the computer and the driver tends to be focused on the details of actually writing the code and
Jeff Terrell: All the syntax details and all the other things and the navigator tends to focus on the big picture and reviewing what's being written so navigator can use his or her mental focus to
Jeff Terrell: Not care as much about the details, or at least about constructing what the details should be, but maybe more about where are we, what do we need to do next, what are some of the things that we need to think about at this point.
Jeff Terrell: A tie says a pair programming is great for competition programming. That's interesting.
Yeah.
Jeff Terrell: Roles ideally should be switching frequently, so I don't always abide by this sometimes if there's one programmer, who's a lot more experienced in a particular language or framework or whatever.
Jeff Terrell: It makes sense for them to drive initially and to spend some time just letting the other person just soak in the technologies and get to know the
Jeff Terrell: The various languages and frameworks sort of by immersion, but at some points. Ideally, not too long after that the the other person should drive and actually practice expressing themselves.
Jeff Terrell: In that language or whatever. But if you have two people who know the language or the module or whatever is being worked on fairly well then you can switch actually fairly often. One of the things that
Jeff Terrell: I've seen people do is what they call ping pong, which is related to test driven development as well.
Jeff Terrell: One person writes a test the other person makes the test pass and the rice. The next test and then the first person writes the mix that second test pass and you kind of ping pong back and forth that way.
Jeff Terrell: Ideally pairs should switch frequently as well so you don't pair with the same person, every time that you're pairing with different people. And this is a way to share knowledge among the team.
Jeff Terrell: Remember XP one of its values is communication and trying to get everybody on the same page about what's being built.
Jeff Terrell: So that's a really good way to do that and share knowledge is by pairing with different people.
Jeff Terrell: Right, so that's a bullet point
Jeff Terrell: Okay.
Jeff Terrell: In pair programming kind of wasteful, though. I mean you got two people in one computer, wouldn't it be more efficient if you had two people on two computers and you weren't doing pair programming at all. But you were just
Jeff Terrell: Having two threads of execution both working on making progress. You'd be surprised. Actually, the results. Various studies have shown that some at worst pair programming is about 25% wasteful of effort and time. But actually, in many cases, it is about equivalent to
Jeff Terrell: Actually independent programming some cases it can even be more efficient, which is kind of surprising.
Jeff Terrell: I think the main reason for this is that you tend to maintain a lot higher focus
Jeff Terrell: I mean, let's be honest, straight at how often when they sit down to program, especially when we get to something hard
Jeff Terrell: Do we kind of get distracted and maybe not focused super hard on what we're working on and what we need to be doing.
Jeff Terrell: Well, turns out and maybe no surprise when you think about it, that's if you're a pair programming, you tend to get less distracted, right, you've got some sort of accountability right there.
Jeff Terrell: To call you if you're getting distracted and say, Hey, let's focus, you know, and even just the presence of another person tends to focus you a little bit because you have
Jeff Terrell: You don't want to disappoint them. And if you're going off and thinking about other things or doing other things, then, then there's kind of some emotional resistance to doing that because you don't want to disappoint the other person maybe
Jeff Terrell: Another thing is that you've got two sets of eyes on the same code as it's being written. So the code quality tends to be higher.
Jeff Terrell: Some bugs that would be bugs tend to be caught fairly early even by the navigator watching what's being written. And so a lot of bugs that might otherwise be introduced just aren't introduced and so you don't spend as much time chasing bugs later on.
Jeff Terrell: If you get stuck in kind of a debugging quagmire of for one thing I would say, remember you're debugging roles that you learned from the book.
Jeff Terrell: But also having somebody else there to to talk things over with can really help you get unstuck and
Jeff Terrell: You know, there's a different perspective that that other person brings there's different set of experience that that person brings and so
Jeff Terrell: A lot of times debugging can go a lot more smoothly and a lot more steadily just steadily making progress and figuring things out.
Jeff Terrell: When you're thinking out loud and you're talking with another person and you're sharing ideas back and forth. You may have heard the term rubber duck debugging. This is talking about.
Jeff Terrell: The. I don't know if this is a true story or not. But the story goes, a programmer realized that every time.
Jeff Terrell: They got stuck on a bug. A thing a head against the wall for a while and eventually start to write an email to their team.
Jeff Terrell: And once they wrote the email before they even sent it. They realized something that they hadn't been thinking about, and they were able to solve the problem.
Jeff Terrell: So they just invested in a rubber duck. And every time they ran into a problem they talked to the rubber duck.
Jeff Terrell: And explain the problem to them and the rubber duck health, even though the rubber duck couldn't talk
Jeff Terrell: So there's the rubber duck factor, but then there's also the fact that this is more than rubber duck that your pair programming with this is somebody who actually has thoughts and opinions and perspectives of their own.
Jeff Terrell: And might be able to know what the problem is. So, so that helps and he can save some time there as well and I talked about this already. Pair programming. It's at most 25% slower, but often on par with or even faster than solo programming.
Jeff Terrell: Okay, there are some difficulties with pair programming, though, that are worth talking about. One is that it can be hard just to verbalize your thought processes.
Jeff Terrell: Sometimes you get in the flow of programming and you're just typing and if you have to stop to explain what you're doing that slows you down and it's hard.
Jeff Terrell: That's something you get used to. You really do. As you do this more often you get better at explaining what you're doing and sort of thinking out loud and talking through what you're doing, even as you're doing it.
Jeff Terrell: But it is it is a skill that you have to learn. And if you're starting out pair programming, then that might be
Jeff Terrell: difficult at first.
Jeff Terrell: Also, we already are using our verbal circuits when we're writing code, at least to some extent.
Jeff Terrell: But actually talking with somebody for most of your day. For example, if you're a professional programmer and it's doing pair programming all day. That's tiring you exhaust your verbal circuits and it is, it can really get tiring. So
Jeff Terrell: Yeah, that's that is a difficulty. It can also be difficult to just coordinate times to work, especially when you're not a full time programmer.
Jeff Terrell: But in, as is the case in this class. You've got a lot of other things going on other classes that you're taking maybe a job and trying to find times that you can actually just work with your teammates can be a challenge as well.
Jeff Terrell: And then just getting in front of somebody and sort of live coding in front of them can be a challenge.
Jeff Terrell: We don't necessarily feel comfortable getting up in front of people, at least some of us don't and maybe making a mistake or maybe doing something dumb or feeling down or feeling self conscious and
Jeff Terrell: You know, that can be a real source of difficulty in pair programming and a big source of resistance, why you don't want to pair program.
Jeff Terrell: I would say just remember XP value number for courage. That's one of the core values of XP and so you could practice your courage and try to
Jeff Terrell: To sort of push into that and get more comfortable doing that for all the benefits that can come from it that we'll talk about in a minute or right now.
Jeff Terrell: Okay so benefits.
Jeff Terrell: Yes, you're sharing knowledge about the code base, and even code that's written is already understood by two people because it was done in a pair programming context.
Jeff Terrell: There are more Deb's that know about each piece of code, and they're each dev also knows more about the total code base their understanding of the code base. Maybe they personally seen up close to 70% of the code base because they've been involved in a lot of the writing of it.
Jeff Terrell: And so
Jeff Terrell: Fewer areas of the code base, have a truck number of one. And what this is is
Jeff Terrell: Basically saying how many people have to get hit by a truck before we're in trouble.
Jeff Terrell: So if they're if there's good redundancy of knowledge among the team, then you have some some good resilience in terms of somebody
Jeff Terrell: You know, hopefully, nobody gets hit by a truck. Hopefully, nobody actually is out of the pocket at all. You know, maybe somebody gets sick, and somebody has to
Jeff Terrell: Leave work for a little while, so it's nice to have some resiliency and redundancy there.
Jeff Terrell: It turns out that people, most people maybe not everybody, but most people really enjoy this even people who are initially resistant to the idea and feel very uncomfortable with the idea
Jeff Terrell: It turns out to be pretty fun. A lot of times to feel like you're actually doing more of a social activity and sharing what you're you're doing
Jeff Terrell: You're gaining respect from your teammate and you're you're learning to respect your teammates more and there's a feeling of camaraderie and loyalty that comes along with it.
Jeff Terrell: Right, Jake mentioned if nobody else understands your code, then you can't get fired.
Jeff Terrell: This is true anti social behaviour turns out to bite you in the long run, but
Jeff Terrell: Yeah, Kim can have the appearance of
Jeff Terrell: Of benefiting you in the short term.
Jeff Terrell: We have super programming is it really can be fun. You can learn and grow faster, as a developer, because you are sort of getting sharpened by this experience of pair programming.
Jeff Terrell: You also get to grow as a communicator and maybe even as a teacher to just be able to explain things that you're doing, or like talk through things with somebody
Jeff Terrell: You tend to get better at explaining things and communicating yourself and even communicating complex ideas. So that's always a plus.
Jeff Terrell: And finally, it can be challenging as a programmer to learn some of the ancillary things about programming.
Jeff Terrell: You know, there can be just little tools and tricks about how to use get how to use your editor, how to use the COI these things totally come up in a pair programming contest, but it's a little bit difficult to get exposed to them.
Jeff Terrell: When you
Jeff Terrell: Aren't pair programming. I mean, how else are you going to learn some of these things.
Jeff Terrell: Right, so some chat about just that last point I was assuming
Jeff Terrell: Everybody's being sarcastic here. Yeah. So, job security, if nobody understands your code here. I really complex code. It has a feeling of job security. Probably yeah okay being sarcastic. Yeah. Probably not a good idea.
Jeff Terrell: You know anti social behaviour.
Jeff Terrell: What's, what was the simplicity right XP value number two simplicity that definitely fights against simplicity. All right.
Jeff Terrell: Okay, just making sure we're being sarcastic about those things.
Jeff Terrell: Okay XP prayer. Well, any questions about pair programming. Before we move on, I think this is one of the things that is the hardest to adopt well
Jeff Terrell: Some of the other ones are pretty challenging as well. This was all flying in the face of the typical ways that people write software. And I think this is a lot of the reason why
Jeff Terrell: Well, I won't say that. Yeah.
Jeff Terrell: But yeah, this, this was a challenge for people to
Jeff Terrell: To adopt and it's still a challenge. And I think people who even sort of
Jeff Terrell: Agree with XP and principal have a pretty hard time doing pair programming and doing all of their programming and pair programming. I think technically XP would say you're supposed to do all of your programming in a pair. I don't know anybody that actually adheres to it that's strictly
Jeff Terrell: But anyway, no questions about pair programming. I'll move on.
Jeff Terrell: Alright practice number two is test driven development. This is huge. This is a huge thing that has totally taken over pair programming is still a little bit niche.
Jeff Terrell: Not everybody does it. But it's kind of hard for me these days to find real world software projects that aren't heavily relying on
Jeff Terrell: At least automated tests. Okay, maybe they don't do test driven development where you write the test first but
Jeff Terrell: They are heavily relying on automated tests. And a lot of this was
Jeff Terrell: Became a lot more popular through XP.
Jeff Terrell: So recall we had four core activities of XP and testing is one of those four things, it's as important as coding. That was one of the main reasons why. Maybe. I mean, I guess, I guess, but
Jeff Terrell: One of the main reasons why XP was considered extreme was because testing was made as equally important as coding
Jeff Terrell: Right. So tests are as you as you saw on the
Jeff Terrell: What was it XP value number three, maybe was was feedback getting feedback from the system in this case. So being able to write tests and get feedback from the system about is your code correct hasn't broken anything
Jeff Terrell: So it's a really important source of feedback and ideally that feedback can be really fast.
Jeff Terrell: Hi, I'm talking like sub. Second, if you can get your test suite down to sub second you can get instant feedback on is this code right every time you hit Save you get feedback.
Jeff Terrell: If something's broken you fix it, you'd save you get feedback and it's just this it really gets you in this flow of
Jeff Terrell: Creativity, that feels really good. And it's really satisfying
Jeff Terrell: Test Driven Development every deviated TDD says to write the tests first before you write the code.
Jeff Terrell: And this can be challenging, but it can be a neat way to do your development.
Jeff Terrell: One of the benefits of this is that it means your tests are kind of be to the point you're not going to write tests that
Jeff Terrell: That don't maybe they're redundant or whatever because you're
Jeff Terrell: RSA. This is making sure your code is not over engineered because you're only writing the code that passes the tests, you're not writing extra code so that tends to keep your tat your code simple that again was a core value of XP. Number two, I think.
Jeff Terrell: So this is typically called
Jeff Terrell: There's like three phases, if you heard hear somebody say read green refactor that's referring to test driven development. The idea is that you write a failing tests, which often shows up as read in a
Jeff Terrell: In your output. And then you make it past by writing code that makes the test pass. So that would be actually implementing whatever feature you're trying to implement
Jeff Terrell: And then the test output shows up as green. And then once it's green you refactor your code you clean it up and keep that test passing keep it green. But as you're keeping it green you're cleaning up your code and making it simpler. So red green refactor.
Jeff Terrell: Right. And I mentioned this already like as you get feedback from your tests, especially if it's a really fast feedback you can get in this creative flow state that is it's a lot of fun to be in you really feel
Jeff Terrell: Like you're, you're just getting stuff done, you're, you're making progress, you're not getting stuck. And that's a good feeling.
Jeff Terrell: Part of the reason I think why some people find programming addictive is is because of this flow state.
Jeff Terrell: Okay, questions about test driven development.
Jeff Terrell: If not, I'll move on.
Jeff Terrell: Okay.
Jeff Terrell: XP practice number three. They wanted to cover is refactoring. I said, red, green refactor. So we've seen that term already
Jeff Terrell: Remember core value number two simplicity and remember Gagne yeah ain't gonna need it.
Jeff Terrell: Remember we were going to focus because of the agony and simplicity, we're focusing on the feature that we need to implement now and we're not worrying about the future.
Jeff Terrell: Or some some future need that we might have. And as a consequence, if you get to a future need that means you've got to extend what's already been written. You have to redesign and existing approach in light of new requirements.
Jeff Terrell: So as you redesign these things you have to refactor. You have to engage in this refactoring process. And you can do that redesign first
Jeff Terrell: By refactoring what's there before you start to extend it so you know refactoring chain is technically means changing the implementation of an approach without changing its behaviors.
Jeff Terrell: So I'm getting distracted because I'm realizing I might have
Jeff Terrell: My face might have been over over top of the
Jeff Terrell: Text. A minute ago. So if that was the case, sorry. I'll try to be more careful about that.
Jeff Terrell: Maybe I'll do this, I hope. All right.
Jeff Terrell: Um,
Jeff Terrell: Where am i right so so refactoring is technically changing details, but not changing that behavior.
Jeff Terrell: Okay. Anyway, if you have feedback from your tests that tell you if anything gets broken
Jeff Terrell: Then it can be really easy to do refactoring because you make a small change you hit save and hopefully you still see everything green
Jeff Terrell: If you don't, you know what small set of things you changed since the last safe point and you can quickly identify what the issue is. Or just undo a few times and get back to a green state and try again.
Jeff Terrell: So this, again, we see that testing and having a good set of tests can be a key enabler of XP core value number for courage.
Jeff Terrell: Sometimes you have to change the unit tests as well as the code so that does happen from time to time.
Jeff Terrell: Yeah, be aware of that tests can add some inertia to your code that might not exist. Otherwise, but I tend to think it's worth it.
Jeff Terrell: And then the other thing other place to see refactoring. As we noted noted in the discussion of test driven development is every time we
Jeff Terrell: write tests and then make them pass by writing code, and we want to clean up that code, maybe also clean up the tests.
Jeff Terrell: And keep things as simple as we can and that that process involves refactoring as well. So refactoring is actually a pretty significant part of the coding that you'll do
Jeff Terrell: Let's do that. Maybe. Okay.
Jeff Terrell: Refactoring is a significant part of the time that you'll spend on code is on refactoring significant part of the time you'll spend on code is on writing tests.
Jeff Terrell: You might spend approximately equal amounts of time on the red phase, the green phase and refactor phase.
Jeff Terrell: So that kind of turns things on their head a little bit. If you think about, you know, if you weren't exposed to some of these ideas.
Jeff Terrell: You might think that you're supposed to spend all of your time on on coding and maybe spend a little bit of time at the end on, just making sure it all works with test manually testing it, but
Jeff Terrell: I find that when I do this kind of test driven development approach. I probably spend approximately a third pressure personal equal time on each of those phases.
Jeff Terrell: So if that happens to you is, you're not doing it wrong.
Jeff Terrell: Okay, I think I might need this move a little faster. I need to end by 340. So we have time for quiz number for today.
Jeff Terrell: The last practice of XP that I wanted to discuss
Jeff Terrell: Was collective code ownership.
Jeff Terrell: And the idea of this is that everyone is responsible for all the code.
Jeff Terrell: It's not like one teammate owns this section of the code. Another teammate owns a section of the code and never the two shall meet. It's really
Jeff Terrell: You have to be responsible for all the code and you can't sort of reserve the rights to be the only person that edits any of the code. Everyone is responsible for all the code.
Jeff Terrell: So each developer has the authority to change any part of the code.
Jeff Terrell: This is where a lot of the XP values are become pretty important.
Jeff Terrell: Having things simple means that you can understand what the code is more easily have encouraged to change somebody else's code. The tests are a key enabler of that because you'll know if you break it.
Jeff Terrell: YOU'RE RESPECTING what somebody else wrote, so hopefully you're not just going in and making trivial changes to suit your style, but you're making substantive changes in a respectful way.
Jeff Terrell: And right I just said this unit tests really help give you confidence that you're
Jeff Terrell: Yeah, my yeah there we go.
Jeff Terrell: That if you break something you'll know about it. So tests. Again, just a key enabler of a lot of extra practices, especially being able to be courageous and make changes.
Jeff Terrell: Okay, so those are the four things I wanted to pick on as far as XP goes that I thought were pretty important.
Jeff Terrell: This is all pretty interesting stuff, I think, but some of it is a little bit more relevant for us. We've already seen continuous integration. So I talked about that when we talked about get
Jeff Terrell: But the basic idea of that is to just stay up to date with what's in master at least fast the trunk based development interpretation of continuous integration.
Jeff Terrell: Other interpretations might involve merging more often from master into your feature branch, but anyway.
Jeff Terrell: Let me, let me just say one word about sustainable pace. This last night program or welfare practice.
Jeff Terrell: The idea there is that you're working 40 hours a week, and you're not working anymore, you know, assuming full time, effort on a software project.
Jeff Terrell: And the reason for that is that you only have so much in you. And if you start to burn past your sustainable rate.
Jeff Terrell: Then you're going to start to eat into your reserves and you're going to burn out. If you do that for long enough.
Jeff Terrell: And even if you don't burn out. You need to kind of rest and recuperate and restore some of those reserves, otherwise you'll start to get
Jeff Terrell: If not burned out, it'll at least start to get harder to be productive because you'll be more fried you'll be more more tired. So this sustainable pace says basically do your best to not work more than 40 hours a week.
Jeff Terrell: And if there's really a good reason to and you need to do that one week plan on taking time off the next week to compensate for that. And this is also also a way to
Jeff Terrell: Make XP more fun. I mean, honestly. Maybe I should still slide about this. Maybe it was important enough but you know you're, you need a fair bit of energy and
Jeff Terrell: Focus, to be able to do things like pair programming and test driven development. So making sure that you're working at a sustainable pace helps you actually do these practices.
Jeff Terrell: Okay. No questions about this.
Okay.
Jeff Terrell: Let's do a poll
Jeff Terrell: Me enable this pull
Jeff Terrell: One second. Okay, there we go, should be active now polivy.com slash Jeff Terrell
Jeff Terrell: Okay, it looks like most of you are satisfied and second best category is somewhat satisfied. So there are a few of you who are neutral or somewhat dissatisfied or completely dissatisfied. So
Jeff Terrell: Yeah, that's unfortunate, but it looks like most of you are at least somewhat satisfied. So I'm, I'm, I'm pleased to see that.
Jeff Terrell: If you're not satisfied, I would encourage you to use your assertiveness skills or dear man skills and maybe your relational skills as well.
Jeff Terrell: And try to have a conversation about why you're dissatisfied. Try to try to just raise the topic and have a conversation about it and see if you can get to a point of understanding and appreciation for your team.
Jeff Terrell: It could be that y'all are just on different pages about who does what and how much each person is working and and perhaps things can be pretty easily resolved so
Jeff Terrell: If you need help with that you can feel free to meet with me one on one or you might be able to bring it up with your mentor as well so
Jeff Terrell: Yeah okay well I wanted to check in about that.
Jeff Terrell: Okay, so moving on, check the time okay 20 minutes. Other agile practices retrospectives
Jeff Terrell: This is not part of XP, but I think it's really important.
Jeff Terrell: XP. I think might include something like this, but it's not one of the sort of core practices.
Jeff Terrell: So I'd recommend at the end of every iteration, which might be every other week might be potentially a little bit longer for you, considering you're not working on this project full time. But at the end of every iteration of work then sit down with your team and ask
Jeff Terrell: What well over the past iteration. Let's list out some things that that we think actually went well.
Jeff Terrell: And also ask what didn't go well.
Jeff Terrell: After that, and you can do all this in parallel on a Google Doc.
Jeff Terrell: Just add a bunch of bullet points and you can collaboratively edit it for a minute or two until you've kind of exhausted all of your thoughts about it.
Jeff Terrell: Then you can vote on 123 topics from each category to dissect and discuss
Jeff Terrell: Discussing good things and dissecting them can help reproduce the success next time.
Jeff Terrell: And dissecting bad things can help understand what the nature of the problem was and help you avoid that problem in the future.
Jeff Terrell: The whole thing really helps you
Jeff Terrell: Get feedback and iterate on that feedback to a point of
Jeff Terrell: Just improving your processes.
Jeff Terrell: And also just having good communication between your team, you know, kind of clear the air.
Jeff Terrell: Making sure there's no simmering resentment among your team to try to get the issues out into the open so that everybody can talk about it.
Jeff Terrell: You can do this with your client or you can just do it with your, your dev team. You could also do it with your mentor to get some your mentor to to guide you in this or give some feedback that could be anything for your mentor to see if you feel safe. Doing it there.
Jeff Terrell: It can be tricky thing to do, just for helping everybody feel safe enough to talk about what didn't go well and to dig into those kinds of issues.
Jeff Terrell: As you practice this, I think, what will happen is that you will gain respect for your team and you'll gain trust for your team and you'll have more courage to do that in the future. So this is a good habit to get into.
Jeff Terrell: I would say it might be worth
Jeff Terrell: trying it sometime soon with your team, especially maybe in reflection on the walking skeleton assignment.
Jeff Terrell: Try it, give it a shot. See how it goes. See if you can sort of have the courage necessary to to talk about things that didn't go well and to
Jeff Terrell: Even dissect, why not this, this doesn't have to be blaming, but it can be a really useful conversation to have to avoid issues in the future and get things out in the open. So might be worth a shot. If you feel safe doing that.
Jeff Terrell: Alright, another practice. I wanted to talk about is just how to have client meetings. So another thing that you can do at the end of an iteration.
Jeff Terrell: Is just meet with your client.
Jeff Terrell: And the way I would recommend these meetings go is to show your client what you've done recently.
Jeff Terrell: This is where travel can be a big win. If you have your board up to date. You can have a column that just says to show an iteration meeting and you can just walk through all the cards in that column and talk about each one in turn
Jeff Terrell: So that could be kind of a stage of work in your terminal board.
Jeff Terrell: Ideally all mentioned that you should have the future. The future deployed to at least a staging environment if not production.
Jeff Terrell: And this means that it is done, from your perspective, unless the client has something they want to see changed.
Jeff Terrell: This is done. You don't have to do any extra work on it. You don't have to go back and remember anything about it. It's already deployed.
Jeff Terrell: And then the client can actually interact with the future, the future. They don't just get to see it and see you interact with it. They get to play around themselves.
Jeff Terrell: And then inviting feedback from your client does anything I'll cough. Now that you see this. Do you have any new requests that you hadn't thought, thought about this is going to happen a lot, by the way.
Jeff Terrell: It's very common for a client to see something and say, oh, you know what we could do, you know, and they'll see something and then something will occur to them like, Yeah, we could do this.
Jeff Terrell: And it'll be a new idea that they hadn't thought of before. This is part of why we be agile. That's why we try to be agile is to accommodate things like this because those things are important and you can't expect your client to know everything in advance.
Jeff Terrell: The next thing to do in your meeting is to establish priorities for the next iteration. So you can ask what is the most important thing to the client at this point in time.
Jeff Terrell: Note that the priorities can be informed by your feedback. I thought relative effort. Ideally, there's kind of a
Jeff Terrell: Conversation that can happen in a collaborative decision about these are the things that are most important to the client. This is the priority order.
Jeff Terrell: But these are the weights of each one of those in terms of effort. And so the client might say,
Jeff Terrell: You know what this. This is the third priority for me. But if it's going to be that easy to do, I'll do that first. And this first one. That's a top priority was actually harder. So I'll do that later. So that's a good collaborative decision they can be made.
Jeff Terrell: What an interesting one other thing, this, this actually came up. I was talking with the student about this recently and
Jeff Terrell: If your client. So one of the things to
Jeff Terrell: Help your client understand is, there's a limited amount of resources in terms of your time to work on this this project. And as much as possible. You're trying to help them and work with them to optimize the use of that time.
Jeff Terrell: And so basically what you're trying to say is, like, you know, my time is constrained. Help me. Use it most effectively to serve you.
Jeff Terrell: I want to deliver the most value that I can, and the limited time that I have. So what are your priorities.
Jeff Terrell: At some point we're going to have to say the products over and I don't have any more time to work on it.
Jeff Terrell: So we have that constraint hanging over our heads and if every step we focus on the things that deliver the most value to you.
Jeff Terrell: Then we'll feel confident that we've done the best we can do in the limited amount of time available, but this kind of conversation can really help connect your client with the very real constraints of the project.
Jeff Terrell: You can also have a retrospective with your client to talk about what went well and what didn't go well, especially with regards to client developer communication. So at the an optional thing that you could do in a client meeting as well.
Jeff Terrell: Okay, um,
Jeff Terrell: Agile practice number seven. And the last one that I want to talk about today is to show value to your client early and often.
Jeff Terrell: We talked about how from a business perspective, it makes a lot of sense that a lot of software projects would adopt a fixed timeline and fixed budget.
Jeff Terrell: Because it feels more definite to clients they feel like okay I can get what I need and three months is kind of costume this much money and at least now that's a known quantity that I can use as I'm thinking about whether it's worth it.
Jeff Terrell: And as I'm making my plans. The problem is that in practice they often are not more definite with that initial impression does matter to to make the deal actually happen.
Jeff Terrell: It can be difficult to engage or to convince your client to convince a client to work with you anyway. But it will be especially difficult if you can't meet them where they are and offer them something definite to work with in terms of time frame and budget.
Jeff Terrell: But I don't recommend doing that for an Agile software.
Jeff Terrell: development process. I think agile development processes work a lot better. And so there's a bit of attention there of how do we reconcile this
Jeff Terrell: This difficulty about wanting to do things different ways. How can we show a client. Hey, we're going to be a great team for you.
Jeff Terrell: But you have to trust us initially because we're not converting to a time from up front because we we we know better. We know that's not going to work out for you in the long run.
Jeff Terrell: But that's a lot to ask of somebody who maybe you just met. Trust me, I know what I'm doing this. I'm asking you to do something differently, you should trust me it's a big ask
Jeff Terrell: So the sort of general recommendation that I have for this is to try to convey value to your client as soon as you possibly can.
Jeff Terrell: Ideally, get a clickable prototype after a week or so maybe dig deep on what do they need. Why do they need it. What is their perspective, like let me understand a day in the life with my client and really embed myself in their
Jeff Terrell: Position so that I can try to understand their need from the inside out.
Jeff Terrell: Go off build a clickable prototype come back show that to him. And this is a way to show value to your client. Hey, I understand what you need. I'm I'm understanding this. I'm getting there and
Jeff Terrell: I'm showing you. I'm showing you the progress that I'm making. And so this is this is a trust building exercise.
Jeff Terrell: And then as soon as you can after that start working on a walking skeleton and get that deliver it as well. And this is this is going to be huge for your client to see you can move fast. You can get stuff done. And if you focus on the walking skeleton.
Jeff Terrell: Over, you know, completeness of all the features, but just to deliver something that is at least locking even if it's not complete that really helps your, your client feel better about hey I can work with these people, they, they know what they're doing.
Jeff Terrell: They've already given me useful things and they're continuing to work on it. So I feel better about it. I had to trust him for a couple weeks at the front, initially, but
Jeff Terrell: They also had to trust me to pay them for their time. So, you know, there was an initial period. But now we've established and trust that we can build on that.
Jeff Terrell: And that's one of the reasons why I require walking skeletons as nerve wracking as it can be, because this is a super useful thing whenever you have to work with clients and understand what they are.
Jeff Terrell: Is a really good tool to have so that you can set up an agile approach to a software project that's going to serve you and client well in long run
Jeff Terrell: For bigger projects, there's still going to be a need for the customer to say
Jeff Terrell: I still need to have a sense of what this is going to take
Jeff Terrell: And so there can be a bit of a given take here. You can do a planning an exploration phase first to identify the biggest risks and try to tackle those as a sort of spike, as it's called, just get a sense of, is this idea going to be viable at all.
Jeff Terrell: But identify some of those risks, try to overcome some of those risks, the risk the project and then provide some rough estimates probably padded a fair bit to give us sort of not to exceed them out.
Jeff Terrell: And then proceed in an agile style billing billing by the hour and always giving updates on where the project is and what the budget is
Jeff Terrell: Okay.
Jeff Terrell: All right, questions about any of the practices agile practices we talked about
Jeff Terrell: Reflection, and when I call retrospectives client meetings and show value early and often.
Jeff Terrell: Okay.
Jeff Terrell: Keep going with combine and Scrum. Let's talk about combine this originated at Toyota in Japan there assembly line. It means billboard in Japanese.
Jeff Terrell: Or signboard maybe
Jeff Terrell: The idea of this is that all work is represented by cards and the workstations or stages of work I represented by columns on a board. And so the cards flow from left to right as work is completed.
Jeff Terrell: Sound familiar
Jeff Terrell: It should, that should be what you're doing with travel
Jeff Terrell: Travel is definitely a lot of people do as a con bond style of work with fellow co doesn't have to be used that way, but it's it's pretty commonly used that way. And that's kind of what I have recommended and set you up with
Jeff Terrell: So you're already doing this in your trailer board.
Jeff Terrell: There are a couple of ways in which you can adhere to combine more strictly and if somebody you might impress it, you know, if you go in for an interview.
Jeff Terrell: And they say that they do combine or something like that. You might impress them by asking them some of these questions like, when you say you do combine. Do you mean this. You mean that
Jeff Terrell: So one of the ways in which you can more strictly adhere to combine, but many people don't is you could say cards should never go from right to left. So you should never go backwards. If you need to discuss something or if there's some sort of a bug or issue with a particular card.
Jeff Terrell: Throw it away, start a new card over and start that one moving from left to right.
Jeff Terrell: I don't usually see people do that. But that that's technically I think what you're supposed to do and kind of on
Jeff Terrell: Another thing is, and this, this actually makes some amount of sense to me. Although I've never actually adopted at myself. Each workstation should have a limited capacity of work in progress.
Jeff Terrell: The more work that's in progress, the more distracting the work environment is and the more context switching that you have to do, which is just overhead. And so if you can really stay focused and only have a minimal amount of work in progress.
Jeff Terrell: You tend to be more efficient. As long as you're not starved for work and so
Jeff Terrell: Some people actually practice this, and they'll say, you can have at most three cars, since there's three developers, you have at most three cards in any one of these workstations.
Jeff Terrell: And if you're wanting to bring in another card over into a column that's already full, go find a different card to work on and move that along to start to clear out the pipeline and get some get some work in progress, finished.
Jeff Terrell: So that would be stricter combine
Jeff Terrell: Okay, let me talk about Scrum.
Jeff Terrell: This is broadly similar to XP, there's a lot of overlap between Scrum and XP.
Jeff Terrell: One quibble that I have about Scrum is that they use the term sprints for like every week or two week period or whatever the team decides
Jeff Terrell: And I think this conflicts with XP practice number 12 about a sustainable pace. Nobody can sprint all the time. That's not a realistic word maybe sounds nice, but
Jeff Terrell: I don't really like the idea of something sounding nice but not being an accurate word that's my personal preference. So I do like the term iteration better than sprint. And that's actually what we use at the company I worked at last, not my idea, but it's an idea that I like.
Jeff Terrell: Anyway, I'm not going to talk about all the ways in which Scrum is similar or different than XP, but I will talk about maybe its defining characteristic which is that you have daily meetings which you might call a scrum or a scrum meeting or stand up.
Jeff Terrell: This is going to happen every day, typically in the morning. Every workday, I should say, typically as early in the morning as you can with everybody there where every team member each team member goes around and says, Okay, what did I do yesterday.
Jeff Terrell: What do I plan to do today and Do I see any obstacles to me, achieving my goals for the day, or to the team achieving its goal, either for the day, or for the iteration.
Jeff Terrell: Just intended to be, you know, you spend like a minute per person like move pretty fast.
Jeff Terrell: Get it done the whole thing, it should start on time and be limited to 15 minutes. Somebody late, they're late and maybe they can go last or something like that. But you don't hold up the whole team because some of these late
Jeff Terrell: But that's, that's a pretty typical characteristic of Scrum. And that's something that a lot of software teams will do
Jeff Terrell: Its intended to be really lightweight, but just a minimal amount of information sharing to so that everybody can be on the same page about what's being done.
Jeff Terrell: And it's a chance for, you know, you see, I'm working on such and such module and somebody else can say, oh, you know what, I know that module pretty well. I could pair with you later today. If you would find it helpful. Okay, good to know. You know that. That's great. Keep that in mind.
Jeff Terrell: Okay, so I think we're on time here. So let me just summarize agile practices and then we'll do our quiz.
Jeff Terrell: Maybe pause for any questions as well.
Jeff Terrell: Um, we talked about pair programming.
Jeff Terrell: Alright, two people on one computer. This is a good way to share knowledge and communicate to to build a similar model of what we're building and everybody's had so replicates that knowledge and each head.
Jeff Terrell: It's fun, it's enjoyable helps you stay focused.
Jeff Terrell: Although it is, it can be difficult. We talked about Test Driven Development read green refactor write your tests.
Jeff Terrell: Make the tests pass by writing code and then clean up your code to make it simple.
Jeff Terrell: We talked about refactoring clean up your code and keep it simple. Yeah, just keep keep things simple and there there are good ways of doing this, especially when you have tests supporting you.
Jeff Terrell: We talked about collective code ownership. So you have full authority to change any code and you have full responsibility for all code, you should change code that is bad. If you notice it, even if it's not code that you wrote
Jeff Terrell: We talked about retrospectives what went well, what didn't go well why and why not discuss with your team. And this is a good way to communicate to establish trust to improve your processes.
Jeff Terrell: Improve your camaraderie.
Jeff Terrell: For client meetings I recommend doing some SHOW AND TELL soliciting feedback from the client and then establishing near term priorities with collaborative decision making.
Jeff Terrell: I recommended showing value early and often.
Jeff Terrell: The goal of this is to win initial trust and buy in for agile methods from your client and then keep that trust. Keep that buy in by continuing to show value as you go.
Jeff Terrell: We talked about
Jeff Terrell: Combine left to right flow of cards on a board and limited work in progress, if we're being strict about it.
Jeff Terrell: And finally, we talked about Scrum.
Jeff Terrell: Which the the main characteristic and defining feature of Scrum is that you have daily stand ups with brief status updates. One thing I forgot to mention is that
Jeff Terrell: The reasons, called a stand up meeting is that everybody's supposed to stand up as a reminder that the meeting needs to be short.
Jeff Terrell: Should be short enough that it's not uncomfortable to stand up for the whole meeting.
Jeff Terrell: Any questions about what we discussed today.
Okay.
Jeff Terrell: It's time for a quiz for I believe at 240 it should be opened up for, I guess, 340 it should now be opened up for you to take
Jeff Terrell: You're allowed to look at any slides or any online materials that you want. You have 15 minutes from when you start to when you finish. You're not allowed to discuss questions or to collaborate with any person on this quiz.
Jeff Terrell: And I will be around watching pizza, as well as I'll mute myself but i'll be I'll still be in this zoom meeting and watching the chat window. If you have any questions about anything.
Jeff Terrell: And don't wait wait too long to start because the quiz expires at 415 which is also when I'm going to release the results of it and you'll be able to see your questions right Matthew says he doesn't see it. So let me just make sure that it is published. Give me one minute here.
Jeff Terrell: Think I needed to publish it. Yeah, my bad. Okay, should be available now.
Jeff Terrell: Wait.
Jeff Terrell: Now, should be available. Okay, try it. Now if you still don't see it, let me know.