Jeff Terrell: Alright, everybody.
Jeff Terrell: we're going to talk about agile practices today we're going to continue our discussion of agility from last time and talk about practices before we do a couple of announcements.
Jeff Terrell: I of course i've heard about what's happened this weekend, and that is a terrible thing, so I just wanted to remind everybody.
Jeff Terrell: You know if you're stressed or depressed or finding that things you know, life is hard and ways that are unusual then reach out for help, I I heard today, unfortunately, that.
Jeff Terrell: taps has like a several week lead time which is really frustrating I don't know what can be done about that or what other resources there are but.
Jeff Terrell: I guess even that's better than nothing, but anyway.
Jeff Terrell: yeah reach out if you need help.
Jeff Terrell: As a reminder, quiz for is, at the end of class on Wednesday, this will be our second to last quiz of the Semester.
Jeff Terrell: and probably one of the things that's at the top of your mind right now the walking skeleton is due in a week on Monday morning.
Jeff Terrell: I hope that's going well, I hope you he did my warning to start before now on that and yeah hope it's going well, if not remember that the APP lab exists, and you can go to the APP lab for technical help.
Jeff Terrell: mentor and presentation is actually going to be in class next week either Monday or Wednesday that'll be all we do in class next week.
Jeff Terrell: Is mentoring presentations so I haven't really talked about that yet, because it hasn't been coming up yet, but get that on your radar.
Jeff Terrell: it's gonna be a five minute presentation so it's not a long presentation it's a pretty prescribed format and content, I mean there's.
Jeff Terrell: are just certain things that I say you need to cover, and I mean I guess the order is up to you, but you don't have a lot of freedom in terms of what you're presenting you're just telling us all about your project.
Jeff Terrell: So I hope it won't be you know what require a lot of creativity from you to get this done.
Jeff Terrell: should be I hope pretty easy lift, but that is something to be aware of, and I do want all Members to present, so this isn't something that you can just delegate to one team Member I want everybody to participate in the presentation.
Jeff Terrell: And yeah, this is just a fun chance to show off your great work show people what's your architecture is and maybe your clickable prototype I forget if that's on there or not, but some.
Jeff Terrell: yeah and then hear from others in class about what they're up to, so I think it's going to be fun like I said hope it's not anything heavier burden some.
Jeff Terrell: i'm going to randomly pick who goes on Monday.
Jeff Terrell: So everybody needs to be ready to present in class on Monday, you for all we know at this point, might be the very first team to present Monday, when class starts.
Jeff Terrell: And, unlike today, we will try to start promptly, so please be here on time because we've got a lot to pack in.
Jeff Terrell: We have in fact 75 minutes to see her yeah 75 minutes to.
Jeff Terrell: Pack and 13 presentations per class so i'm going to limit you to five minutes, and if you're if you don't finish that.
Jeff Terrell: Presentation by the five minute mark i'm probably gonna you know get the hook out and stuff your presentation not literally a hook, but I will have a timer going see your question yeah one SEC so um.
Jeff Terrell: So I would recommend rehearsing with your team to make sure you get the timing down because, if I if I need to cut you off I might not be able to hear all of your a great presentation and.
Jeff Terrell: might have to take a little bit of points off if I if I didn't hear about or in the class didn't hear about some aspect of your of your project so.
Jeff Terrell: Be ready for that, let me finish, I see a couple of questions here, let me finish just a few things about this and then, if I didn't answer your question, then there will be time for that.
Jeff Terrell: yeah i'm really wanting everybody to be here in person, I know the trend has been fewer and fewer people actually coming to class semester goes on.
Jeff Terrell: and which I i'm generally okay with I like seeing people face to face I feel like it's a lot more fun to present to people in person, rather than over zoom but.
Jeff Terrell: I understand it's nice to have some flexibility there, and you know not feel like you have to.
Jeff Terrell: Come all the way to campus and all that if if you don't want to so so I haven't asked you to do that, in general, but I am going to ask during the midterm presentations as well as during final presentation.
Jeff Terrell: That everybody calm in person, and if you can't like maybe you know you woke up and you don't feel well and maybe you have some symptoms of covert or are waiting on a covert test or something like that.
Jeff Terrell: You know it's more important not to put your classmates in danger, so don't come in that case, and just let me know in advance if you cannot make it.
Jeff Terrell: Whether because you're sick or because there is some sort of a conflict that you have with that you know, hopefully you've been reserving this time.
Jeff Terrell: All semester, I do I have been I think clear about my expectations that you'll be participating, either here or on zoom during class times synchronously so.
Jeff Terrell: I hope you won't have any conflicts, but, but if you do just let me know in advance and we'll try to schedule, you make sure you get scheduled on Wednesday or something like that, but um.
Jeff Terrell: But yeah I am really hoping that we can all meet in person for that I think it'll I think it'll be fun Daniel do you have a question.
Jeff Terrell: hmm I forgot to update, thank you, Daniel mentioned that the assignment on the website says six minutes I had fewer teams present last year.
Jeff Terrell: Last year we did do six minutes and I forgot to update that, but the correct number is five minutes, thank you for noticing that discrepancy.
Jeff Terrell: I think I may be answered your question wally anybody else have any questions.
Jeff Terrell: Okay.
Jeff Terrell: also remember to have your slides available through your website by the start of class Monday that will i'm guessing most of you will do like Google slides or something like that.
Jeff Terrell: But.
Jeff Terrell: Hopefully that will minimize switching times, even if we're doing random orders.
Jeff Terrell: Okay, any questions about walking skeleton or anything else.
Jeff Terrell: Okay.
Jeff Terrell: Today we're gonna We talked quite a bit about agility last time and we focused on some things that I would kind of summarize as the agile mindset.
Jeff Terrell: How to think about agility how to think about change, realizing that change is just a fundamental part of software projects and really a lot of different kinds of projects and that we should build processes around accepting change and handling it gracefully.
Jeff Terrell: Or the trying to resist it so that was a lot of like the mindset of agility.
Jeff Terrell: Today we're going to focus on the practices to do things in an agile way and help us to respond gracefully to change.
Jeff Terrell: Some of these come from xp extreme programming, which we spent some time talking about last time, but there are some.
Jeff Terrell: That don't necessarily come from xp but that I found very useful on projects that i've been involved in, and that I think are not probably none of these are adopted by everybody, but are you know fairly common practices as well.
Jeff Terrell: And we'll finish up talking about con bond and scrum what's your two common terms that come up in agile software projects.
Jeff Terrell: Talk about what those are so start with selected xp practices, if you remember xp extreme programming has four core activities five values and 12 practices.
Jeff Terrell: These are the 12 practices of xp remember this book came out in 99 from Kent back.
Jeff Terrell: Some of these things.
Jeff Terrell: I have never done and as far as I know, are not particularly maybe they didn't really catch on in the industry as much as other things have so i'm not going to talk about every single thing here.
Jeff Terrell: But I am going to spend some time talking about a few of these.
Jeff Terrell: And the first one of those is pair programming.
Jeff Terrell: Quick straw poll, if I had had a little bit more time, I would have prepared an actual poll for this, but anybody done pair programming on some other projects outside of this class before.
Jeff Terrell: A few Okay, maybe three people and one person on zoom couple people on zoom okay.
Jeff Terrell: Great um.
Jeff Terrell: How about anybody done it on this project, yet and for 523 anybody done pair programming for this project.
Jeff Terrell: Nobody.
Jeff Terrell: Nobody all right.
Jeff Terrell: Anybody who hasn't done it heard of pair programming before like you've heard of the idea I haven't done it.
Jeff Terrell: Another few people okay.
Jeff Terrell: couple people online.
Jeff Terrell: Great.
Jeff Terrell: cool just curious but mostly it sounds like from us to be this is kind of a new topic.
Jeff Terrell: So what it is for those of you who don't know is two people sitting at a single computer to write code.
Jeff Terrell: Alright, so it's not two people on two computers within the cubicle or something like that it's actually just one computer and one person has their hands on the keyboard and the other person is just looking at the screen.
Jeff Terrell: The driver is typically what you would call the person with his or her hands on the keyboard.
Jeff Terrell: And you would call the person, the other person the Navigator.
Jeff Terrell: The driver is actually thinking about okay hi this is whatever i'm working on how do I express that in code right, just as you would, if you were doing programming.
Jeff Terrell: And navigator is able to take a step back from that think about well for one thing, just to review what is being written, which requires maybe a little bit less brain power than actually writing it.
Jeff Terrell: But because they have a little bit of extra brainpower they can be they can focus on the big picture.
Jeff Terrell: They can take a step back from the actual mechanics of doing this and that and the implementation and start thinking about Okay, what are some things that we need to consider here.
Jeff Terrell: Maybe what are the next tasks that we should be working on and can help at a higher level navigate the the pair towards getting work done.
Jeff Terrell: Ideally, the roles should switch frequently, so the driver and the Navigator should trade off and the Navigator should become the driver and vice versa that's kind of ideal for a few reasons.
Jeff Terrell: And it doesn't always happen, but one reason that's nice to do that is to.
Jeff Terrell: give everybody a turn give you know, let people take a break from the thing that they were doing and keeps things interesting, it also can be a check for you, if you're the Navigator that you have actually been understanding what's going on.
Jeff Terrell: Sometimes.
Jeff Terrell: Some projects will do this less often like there will kind of be one person who is hogging the keyboard for, for better or worse, and I actually have the keyboard quite a bit I mean maybe that's partially because of my control issues.
Jeff Terrell: And and patients or something but but it's also can be valuable for if one person is a lot more familiar with the technology that's going to be used for the language or whatever.
Jeff Terrell: Then it can be nice to have that person in the driver's seat and have the other person following along and learning.
Jeff Terrell: Now that said, even if there is kind of a mismatch between experience levels on whatever the technology is can be useful to even then trade off from time to time and give the person who's less experienced some practice implementing helps cement some of that knowledge that they've absorbed.
Jeff Terrell: Also, ideally it's nice if you actually rotate between different pair programming partners, assuming that you're working with just more than just one teammate.
Jeff Terrell: The reason for that is that it really helps share knowledge among the team.
Jeff Terrell: Remember xp value number one is communication and communication is about knowledge sharing and if you are actually.
Jeff Terrell: Having a chance if not to work all over the code base at least to see other people work in other parts of the code base that you might not touch otherwise.
Jeff Terrell: That can really help the overall health of the code base and resiliency of the team, you know, for that time that some teammate God forbid gets covert or.
Jeff Terrell: goes on vacation or whatever.
Jeff Terrell: Any questions about pair programming.
Jeff Terrell: there's one I think burning question that a lot of people have about pair programming anybody.
Jeff Terrell: anybody think about what that would be.
Jeff Terrell: When people hear this concept and they're like but wait, what about.
Jeff Terrell: Think about actually doing this okay Osama says isn't it slow, yes, exactly isn't it slow.
Jeff Terrell: which you dedicate two people to one computer why wouldn't he isn't that like half the speed that you'd be moving at otherwise right.
Jeff Terrell: Yes, a summit that's exactly it that's I think is the burning question that a lot of people have about pair programming.
Jeff Terrell: Sure, if you have double the time you need, then you do pair programming but otherwise it's just a waste of time right.
Jeff Terrell: Well, actually no it's not nearly as wasteful, as you might think, in fact, in a lot of cases, it can actually speed up the project, believe it or not.
Jeff Terrell: make up for that last time and then some in some cases.
Jeff Terrell: One thing to think about is that you maintain higher focus right you're you're working with somebody, and this is kind of the same reason that you might get in a study group yeah you could study it on your own.
Jeff Terrell: But don't you think study groups tend to help you stay focused on the studying and maybe are worth your time.
Jeff Terrell: same is true with programming.
Jeff Terrell: All right, we still have to overcome the loss of half of a you know 50% loss and hands on keyboard time so there's a lot to overcome here but but focus makes up for a lot when you are actually staying focused on what you're doing because I mean let's be honest right.
Jeff Terrell: If you looked at the total amount of time that you sort of had set aside to work on a project, how much of that are you actually working on the project and how much, are you distracted.
Jeff Terrell: I mean you know you you check your phone you're waiting for a message from so, and so, and you want to check your phone or you want to check your email or you run into some hard task and.
Jeff Terrell: yeah let's take a little break i'm gonna go check my email, you know, and then you go get distracted by that email that came in you start thinking about something else, and you know you know how this goes right.
Jeff Terrell: Alexander great question can't it also break your concentration have to think about another person, it can it's definitely something that you have to get in the habit of doing so, yes it's different to have to think about another person and to bring them into your concentration.
Jeff Terrell: yep different way of thinking.
Jeff Terrell: But yeah anyway, the point here is focus is one thing that you get that you actually benefit by working in a pair.
Jeff Terrell: Most people well, maybe some people are so discipline that they really do stay 100% focused I don't know.
Jeff Terrell: If anything thing that happens is that the code quality produced by pairs tends to be higher than that produced by individuals.
Jeff Terrell: And if you think about it, this makes sense right, I mean you've got two pairs of eyes on all the code that's being written.
Jeff Terrell: And so, a bug that would have gotten past one person is noticed by the Navigator right the driver write something and it turns out not to be correct.
Jeff Terrell: And the Navigator notices and says Oh, is that right, did you mean to do this or did you think about this, you know that looks like an off by one error or whatever.
Jeff Terrell: that's a bug that the driver didn't catch right, so the Navigator caught it, and that means that you're fixing the bug right away, instead of finding out about it sometime later, maybe when you've lost the context.
Jeff Terrell: So that could be a benefit.
Jeff Terrell: Also, if you're debugging it's really nice to have somebody to talk to you about the bug that you're experiencing.
Jeff Terrell: And they actually have their own perspective and experience that they can bring to bear on the bug that maybe they have the key insight.
Jeff Terrell: I remember a block I was working with somebody else on and this email, that we should have been being sent in was being sent correctly in our test environment, this was not being sent in production and we couldn't figure out why.
Jeff Terrell: And it turned out that there was a not very well advertised limitation of the particular platform, we were using to prevent you from being able to send outbound mail a certain way.
Jeff Terrell: And we didn't know that but, once we got to thinking about I think one of us mentioned it, I don't think it was me actually and.
Jeff Terrell: We looked into it, that was it and it made sense because of the idea of like a spammer using that platform to send spam email.
Jeff Terrell: So that was why that limitation was there, but you know that's the kind of thing that sometimes just having that extra knowledge can make the difference between figuring out the bug and not having that person right there beside you can help.
Jeff Terrell: Anybody heard of rubber duck debugging.
Jeff Terrell: yeah few people okay.
Jeff Terrell: yeah So if you haven't heard of this it's kind of a funny story I don't know if it's true or not, it might just be apocryphal but.
Jeff Terrell: The idea is this one programmer was having would occasionally get stuck and would have difficulty with something and would finally start to compose an email to their team.
Jeff Terrell: describing the problem to get help and when they were writing the email before they even sent it.
Jeff Terrell: They started thinking about how to explain the problem to their teammate and then they realized a gap in their thinking and Sure enough, that was the bug.
Jeff Terrell: That was where the bug came from, so they were able to solve the problem without even sending that email, and they got smart and realized.
Jeff Terrell: what's really important is just explaining the problem, and I can explain the problem, a lot faster speaking than typing so.
Jeff Terrell: They brought their rubber duck in from home and set it on their office desk and and the next time they got stuck just explain the problem to the rubber duck and the rubber duck help them debug.
Jeff Terrell: Even though obviously the rubber duck can't talk.
Jeff Terrell: But pair programming for debugging is like the rubber duck except the rubber duck knows how to Program.
Jeff Terrell: and actually knows the code base and can really help you debug so.
Jeff Terrell: That can help.
Jeff Terrell: And people have studied this problem right, I mean you can imagine, when pair programming started becoming a hot topic software engineering researchers went off and did studies to figure out is this actually wasteful If so, how much.
Jeff Terrell: what's our efficiency lost compared to everybody working alone.
Jeff Terrell: And from what i've read most studies tend to show that pair programming isn't most 25% slower.
Jeff Terrell: But often that should be on par with often on par with or even faster solo programming and it kind of depends a little bit on the timeframes that you measure across.
Jeff Terrell: But it can be on par with maybe even faster than solo programming.
Jeff Terrell: anybody can events like this is worth trying anybody still yeah maybe.
Jeff Terrell: Anybody still like mad doesn't really sound like something I want to try.
Jeff Terrell: I don't mind to get you know it's okay.
Jeff Terrell: Maybe we're still on the fence a little bit and Charles Charles says yeah.
Jeff Terrell: yeah two people sorry pair programming, I meant anybody interested in trying pair programming, yes, on par with two people solo programming sorry I didn't say that well on par with solo programming meaning like.
Jeff Terrell: Your parents twice as productive as a single person.
Jeff Terrell: That would be on par yeah sorry for the confusion there.
Jeff Terrell: um.
Jeff Terrell: yeah I mean there are some difficulties right and maybe some of you are sensing the the challenge of pair programming and are hesitant to try to bite this off knowing kind of how it would be so let's talk about that a little bit.
Jeff Terrell: One challenge is you got to verbalize your thought processes.
Jeff Terrell: And this gets back to alexander's point about breaking your concentration to have to think about another person.
Jeff Terrell: Like if you're actually thinking about how do I verbalize what i'm doing as i'm doing it that's that takes some some time that takes some effort that's a skill that you can acquire but you might not have that skill right now very well, it might be hard to think out loud.
Jeff Terrell: i'll say i've gotten a lot better at this in time I used to not be very good at this at all, but with practice i've been able to get a lot better at it and it's just a skill that you can acquire.
Jeff Terrell: yeah under says, I did pair programming a lot this summer, and it was very helpful because me and the other interns didn't know what we were doing.
Jeff Terrell: yeah it can help you guys can stumble around together and figure it out.
Jeff Terrell: yeah so verbalizing your thought processes can be hard, and if you do very much of this in a given day you can exhaust what I would call your verbal circuits.
Jeff Terrell: And that that's a different kind of tired here, you may not have experienced that before I don't know.
Jeff Terrell: I know, when I was in college I don't think I really understood this nearly as well as I do now, one thing is like lecturing uses my verbal circuits a lot and meetings do some and then the other thing that really wears me out is my six year old daughter.
Jeff Terrell: She burns those variable circuits out and she can go for hours and then, just like Okay, how much do I really need to pay attention to because i'm really tired of words right now.
Jeff Terrell: So this is a special kind of exhaustion that maybe parents know better than most I don't know.
Jeff Terrell: Also, just Logistically it can be hard to coordinate work times if you're trying to find somebody to pair program with.
Jeff Terrell: And you're busy and they're busy.
Jeff Terrell: Another thing there's kind of an emotional block right it's kind of akin to being okay with failure.
Jeff Terrell: Are you are you comfortable like letting somebody actually watch the program because what if you make a mistake.
Jeff Terrell: Or what, if you do something in an ignorant way or a slow way or you know people get to see you and your you think they're going to realize that you're not actually that good of a programmer after all or not not where you should be or something like that.
Jeff Terrell: so that you know those are those are real.
Jeff Terrell: Real things real feelings and.
Jeff Terrell: makes sense that you know you'd hesitate about that, so I think you know, supporting to validate that feeling not not say that that's stupid.
Jeff Terrell: But I think that's something that's.
Jeff Terrell: You know, you can practice being courageous according to xp volume number four and get.
Jeff Terrell: letting yourself be known by your teammates and maybe you aren't as skilled a program or a certain other teammates are.
Jeff Terrell: And that's okay you're doing your best, I hope that if you're more skilled than somebody that you're pair programming with that you respect them remember that's an xp value as well, obviously don't make fun.
Jeff Terrell: yeah that can be a Another difficulty of pair programming.
Jeff Terrell: By the way, if you're starting out with pair programming.
Jeff Terrell: And you haven't practiced kind of the thinking out loud and verbalizing, and I mean it's steady constant communication, it is, it will wear you out a lot more than solo programming well.
Jeff Terrell: So i'd recommend only biting off maybe an hour or it must to that the first few times you do it until you feel like you have a sense for why you're in differences, maybe, maybe you're like my daughter, and you could talk for days and not get tired.
Jeff Terrell: If not, then just start slow don't expect to be able to do it all day every day.
Jeff Terrell: and benefits.
Jeff Terrell: there's kind of a tongue in cheek expression that I heard an industry a truck number, how many people have to get hit by a truck for us to be in in trouble so.
Jeff Terrell: If the if something has a truck number of one, that means that only one person really knows this part and that's a not a great place to be in terms of resilience of your overall team.
Jeff Terrell: So if you're doing pair programming you're spreading knowledge around your your truck numbers are going to be higher, for your code base so that's a good thing.
Jeff Terrell: It turns out, most people actually really enjoy this once they start doing it, believe it or not, it might sound pretty uncomfortable, but when you start diving in and you realize that people aren't going to make fun of you and it's actually kind of fun to work side by side with somebody.
Jeff Terrell: This can be really enjoyable.
Jeff Terrell: I require my tool smith's I work with I don't know handful half dozen tool Smith each semester.
Jeff Terrell: And I require them to do a significant amount, in fact, I think the majority of their time it needs to be spent pair programming.
Jeff Terrell: And so I asked my new tool Smith this semester I explained what pair programming was, and I said I expect you to do this and few weeks into it, I said how's the pair programming going are y'all.
Jeff Terrell: Are you enjoying it doesn't seem worthwhile and everybody was like it's great we enjoy it it's useful we're getting plenty of worked on this is great.
Jeff Terrell: And it was really nice because we had, like some of the tools for more experienced some or less experienced and the more experienced people are starting to bring the less experienced people up and everybody's being productive and it's been really great so consider that, for your project.
Jeff Terrell: You will learn and grow faster, first of all, just by being able to learn from your teammates and benefiting from their perspectives and the different tools and.
Jeff Terrell: and techniques that they use in their craft you'll get to benefit from but also you'll get better at communicating and you know if you want to advance in your career as a software developer and software engineer.
Jeff Terrell: Getting good at communication is a really good way to do that.
Jeff Terrell: You know, if you want to level up communicating and getting better at communicating is is pretty key so pair programming will definitely sharpen those skills.
Jeff Terrell: Also there's like a lot about the craft of programming, that is kind of hard to learn, like the ancillary stuff like how to use your editor well.
Jeff Terrell: Like how are you going to learn that you know I mean you could poke around and explore and whatever, but maybe somebody who's been using the editor for five more years than you can show you things that you've never seen before.
Jeff Terrell: Or you know get maybe.
Jeff Terrell: You go off to your industry job and and you forget all the things I taught you about get me forgot about get blame and the ref log and whatever.
Jeff Terrell: But then you get to pair program with somebody and you remember those things, because you see them use them.
Jeff Terrell: And you're like oh yeah okay that's a really good way to use get i'm going to have to remember that, and these are things that are kind of hard to expose yourself to.
Jeff Terrell: Normally, but they're very easy to get exposed to in a pair programming context so there's a lot of like.
Jeff Terrell: difficult to quantify benefits to this.
Jeff Terrell: And that's all I plan to San pair programming any questions about this before I move on.
Jeff Terrell: Okay.
Jeff Terrell: let's talk about test driven development.
Jeff Terrell: xp practice number two.
Jeff Terrell: This is huge automated testing is a really big part of software development these days i'm going to actually spend like the next two lectures talking about tests.
Jeff Terrell: And kind of how to craft them well to help your project succeed.
Jeff Terrell: Remember testing is actually a core activity of xp one of the four core activities it says important test coding is actually.
Jeff Terrell: And tests are really important, if you do them well, they give you feedback.
Jeff Terrell: Is the code and its current state, correct, you know, including the changes that I made in the last 30 seconds and just now hit save is that code correct or did I introduce a mistake in the last 30 seconds.
Jeff Terrell: Let me just take a step back, I meant to add a bullet about this Fred brooks talks about.
Jeff Terrell: A high level breakdown of time spent in different activities for a software project in his book the mythical man month and I remember reading this I, I may have mentioned this before, but.
Jeff Terrell: I remember reading this and thinking that that's still true today, he said that about half of the time on a project is tests.
Jeff Terrell: A third is for planning and a sixth is for implementation.
Jeff Terrell: And you think of a project is being like mostly implementation work, but actually if you break that down like planning is a big chunk and testing is a big chunk and both of those each of those is actually a bigger chunk than the implementation.
Jeff Terrell: And tests according to brooks where we're about half.
Jeff Terrell: So spending time on tests is to be expected and it's really nice to be able to spend that time writing automated tests that can be rerun later on demand.
Jeff Terrell: But test driven development takes that one step further and says that we are driving the development with tests, in other words we write our tests first and then we write the code that makes those tests pass.
Jeff Terrell: So it feels like it's almost getting the cart ahead of the horse.
Jeff Terrell: But this is what tdd says test driven development and this this was part of xp.
Jeff Terrell: One of the res ways, it was considered extreme they're not the very first ones to do test driven development, in fact, I think I saw on Wikipedia that.
Jeff Terrell: Like some NASA project at this kind of approach to a project back in like the 16th or something so it's not completely novel, but I think that was one of the reasons that xp was considered extreme was because they were insisting on doing tdd for everything.
Jeff Terrell: And at a high level the process goes like this it's called red green refactor.
Jeff Terrell: first phase is called red, which means you write a test that fails.
Jeff Terrell: It fails because it's presumptive it's sort of expecting there to be a feature implemented that isn't implemented yet, and so, of course, the test fails.
Jeff Terrell: But once you have that test, you can use that to give you feedback about when your feature is actually complete according to the behavior that you specified in your test.
Jeff Terrell: So you get that failing tests written that's read and then you write the code to make that test pass that's green.
Jeff Terrell: And the third phase, you know you have a test and code that makes it the test pass, but now you can actually clean up your code and make it simple and you want to go that extra miles because xp you know core value to I think it is simplicity.
Jeff Terrell: And you want that code to be as simple as it can be so that other teammates can understand it.
Jeff Terrell: So you go ahead and refactor you clean up that code make it simple and that's the third phase and, in the end tdd you know the catch line is red green refactor.
Jeff Terrell: Now, this can be a lot of fun if y'all have ever experienced a.
Jeff Terrell: Creative flow State while programming or even doing some other activity, maybe I don't know writing a paper doing something else that's creative, maybe even with your clickable prototype you got into this creative flow state.
Jeff Terrell: or you're just like exerting your will into the system and, like things are taking shape and it's really fun it's just like it's fun to get into that state.
Jeff Terrell: And if you have a good fast feedback loop from your tests it's relatively easy to get into the state.
Jeff Terrell: Because you make one small change you hit save you instantly get feedback from your test whether you are correct or not, if you're not you probably know exactly what the problem is based on both the.
Jeff Terrell: output from your tests and the fact that you only did 30 seconds worth of changes since you were last green, and so the bug is limited to the 30 seconds worth of changes which is at the top of your mind already.
Jeff Terrell: and using those tests as a feedback loop, you can really get into that creative flow really quickly it's really nice it's fun.
Jeff Terrell: And, as I said, we'll be talking quite a bit more about tests in the next couple of lectures, but that's at a high level test driven development xp practice number two questions about this.
Jeff Terrell: Okay.
Jeff Terrell: Jenny asks are there times when we can't write tests.
Jeff Terrell: There are, yes, there are ways where writing tests is hard, one of the things that i'm going to try to do over the next two lectures is equip you to be able to find ways to write tests that still have good value for your code base.
Jeff Terrell: There are things that are harder to test and others, and a lot of this depends on how you structure your code, but, for example, one of the projects that we had last year was a virtual reality project.
Jeff Terrell: And if we were trying to do what's called an end to end test on a virtual reality APP.
Jeff Terrell: In other words, somehow driving the APP through like as though the user we're doing certain things that would probably be pretty hard to write.
Jeff Terrell: But there are ways of writing test is still add good value that are not into and tests in such environments and we'll talk about that it's a good question.
Jeff Terrell: Other questions.
Jeff Terrell: Okay.
Jeff Terrell: So let's talk a little bit more about refactoring that's actually another xp practice.
Jeff Terrell: we're striving for simplicity in our code that's xp value number two.
Jeff Terrell: Technically speaking refactoring says leave the behavior alone.
Jeff Terrell: But you're just changing the implementation of the code.
Jeff Terrell: Another way to maybe think about this is your code has some sort of interface, maybe in terms of which functions or methods are available, what their.
Jeff Terrell: parameters are and how many parameters, they accept and what kind of thing they return and maybe the types that's like the interface of your code.
Jeff Terrell: and, generally speaking, if you if you want to be precise about what refactoring means it means leaving the interface, as it is, but changing the implementation of those various functions to be more simple, without affecting the interface.
Jeff Terrell: and your tests are actually testing the interface like there, I mean maybe that's not the best way to say it, but they're they're using the interface to test the behaviors is a better way to say it.
Jeff Terrell: And so, if they use the interface, and the interface doesn't change as you refactor then your tests are still valid, and you can do a lot of cleaning up of implementation, without affecting the interface, without having to rewrite your tests.
Jeff Terrell: This is really not difficult if if you have a fast feedback loop from your tests, because, again, you just make one small change hit save and you get feedback about whether that one small changes correct or not so maybe as you make the next small change it, save and look at that feedback.
Jeff Terrell: And that helps you be courageous, as you're making changes Oh, I think we could.
Jeff Terrell: change this variable name to be this other thing, let me just do that real quick hit save okay looks like that's good and you're you're more courageous to take these things on because you have those tests that are going to let you know if you broke something.
Jeff Terrell: Now, if you didn't write your tests well or, if you do not need to change your interface, perhaps the interface that you initially picked wasn't as simple as it could have been yeah then you'll need to change the unit tests as well.
Jeff Terrell: So that is a potentially a downside.
Jeff Terrell: But also remember red green refactor you want to refactor before you commit and you don't want to leave off that step, because then you'll get into a kind of a messy code base.
Jeff Terrell: I think we will cover refactoring and more detail, potentially, in the last lecture that I get this semester, but any questions about that for now.
Okay.
Jeff Terrell: Practice number four.
Jeff Terrell: Collective code ownership, this is one that I bet most of you are not doing.
Jeff Terrell: that's okay if you're not no judgment, but I bet This is one you're not doing.
Jeff Terrell: This one says it everyone is responsible for all of the code.
Jeff Terrell: All right, and each developer, has the authority to change any part of the code.
Jeff Terrell: So if you have set up your code base so that such that one person sort of has the keys for the back end.
Jeff Terrell: or one person has the keys for the front end or you have any sort of partition like this, where it's just really just one person who works on this part of the code base.
Jeff Terrell: Then you're not adhering to xp practice number four there's no shame here i'm really not trying to shame you i'm just saying I think this is something that.
Jeff Terrell: The natural way as things evolve, if you don't have some discipline and you're not doing pair programming things tend to evolve in a project, such that.
Jeff Terrell: We have these silos of different people kind of owning this part of the code base and usually you get into a situation where you don't feel empowered to make a change anywhere in the code base.
Jeff Terrell: And you kind of feel like if you've made a change over there, they need to be stepping on so and so's toes.
Jeff Terrell: And this is a bit problematic because what if that person is kind of gets back to the idea of the tracking number.
Jeff Terrell: What if that person needs to go on a vacation and you actually need to get work done in that part of the code base the team does somebody does but.
Jeff Terrell: That person was really the only one who ever worked in that code base and you don't know it and you also feel like that's kind of their personal space.
Jeff Terrell: So then obviously your whole project would slow down because you have this idea of like turf.
Jeff Terrell: And xp practice number four is kind of solution to that saying there's no such thing as turf everybody, you know the whole code base is everybody's turf.
Jeff Terrell: Also, if you have good unit tests in place for all the different sections of your code base then you'll have more confidence to make changes and know if you broke something chops you actually try things out and.
Jeff Terrell: You know iterate towards a solution.
Jeff Terrell: So, consider that.
Jeff Terrell: And pair programming pair programming is a natural complement to this, because then you'll naturally be exposed to different parts of the code base, and it will feel less owned by one person anyway.
Jeff Terrell: Questions about this.
Jeff Terrell: Okay.
Jeff Terrell: Practice five I wanted to mention briefly we've already talked about this continuous integration so i'm not going to spend a lot of time on it i'm just going to remind you about it, because this is one of the xp practices.
Jeff Terrell: And the main idea is just to keep your code current with the the trunk and you know, the main line of development on this project typically like the main branch or the master branch.
Jeff Terrell: So as a refresher you know continuous integration would be, for example, before you start coding each day stash your dirty changes fetch the latest stuff.
Jeff Terrell: and replace your feature branch on top, all of the latest changes before on stashing or dirty changes just keep it up to date, keep it fresh do that every day.
Jeff Terrell: And if there is a conflict of some sorts then it'll be relatively at the top of mind for everybody involved and easier to resolve.
Jeff Terrell: That familiar y'all remember way it's talking about that, before.
Jeff Terrell: yeah okay.
Jeff Terrell: Really, like this one, sustainable pace think this is important that a kind of Meta level.
Jeff Terrell: try not to work more than 40 hours a week.
Jeff Terrell: I mean obviously y'all are in a different situation y'all aren't trying to work 40 hours a week for 523 at least I hope you aren't.
Jeff Terrell: That would probably not be a sustainable pace, given all your other responsibilities, but you know, assuming you're like a full time employee somewhere doing software work try not to work more than 40 hours a week.
Jeff Terrell: Hopefully you'll get into a company that.
Jeff Terrell: Values this as well and won't push you to work more than that.
Jeff Terrell: And if you do work more than 40 hours a week, try to take some time off the following week.
Jeff Terrell: says xp and I also agree with this.
Jeff Terrell: take some time off rest up a little bit catch up on your rest and.
Jeff Terrell: Take it easy don't go into work on a day on one day or something like that why, for one thing, avoid burnout.
Jeff Terrell: This might be an interesting question to ask her mentor it's like hey Have you ever been burned out from work.
Jeff Terrell: What was that, like or do you know anybody who has.
Jeff Terrell: You know, sometimes you really get into hard burnout and it's like somebody was really productive and worked really hard and then it's just not sustainable sprinting for too long, and they just need.
Jeff Terrell: They just need a break it's a real need, and the longer they keep waiting on getting rest and getting a break the harder the burnout is going to be.
Jeff Terrell: And maybe they end up having to take an extended leave of absence, maybe they struggle with depression, at that point.
Jeff Terrell: So much of their life was work up to that point, this is really something you want to avoid and so sustainable pace is saying like don't push it too hard, try to think about what a reasonable thing to do, long term is.
Jeff Terrell: Another reason it's kind of less I don't know severe than burnout is just your energy level think about your energy level if you're pushing a little bit too hard, week after week, your energy level is going to start to suffer.
Jeff Terrell: And these xp practices like especially pair programming they take a lot of energy and take a lot out of you, and so, if you're going to try to actually do these things.
Jeff Terrell: You better be well rested you know, try to be healthy, try to be working at a sustainable pace and that you can keep that energy level high and so that you're able to actually be productive in a relatively demanding environment of some of these practices.
Jeff Terrell: This is one of the terms, I really don't like in the industry, especially like in in scrum I think I have this elsewhere on the slides as well, but I mentioned it here is the idea of a sprint.
Jeff Terrell: People talk about like this rant we're going to do this, and they finish that sprint and say how the sprint go okay next sprint we're going to do that.
Jeff Terrell: And I think that very much flies in the face of this xp practice number six like you cannot be sprinting.
Jeff Terrell: Over and over and over again, with no breaks in between, if you really need to sprint you need to understand that that's going to be for a short term and that you need to rest after.
Jeff Terrell: So manager Is that really what you mean that you want me to sprint, are you willing to pay the price for that afterwards, or do you actually want to sustainable pace and Sprint just sounds nice but that's not really what you mean.
Jeff Terrell: So those are our six xp practices that I wanted to spend a little bit of time talking about any questions about anything here.
Jeff Terrell: cool maybe that gives you some food for thought, you could of course discuss this with your team and see if you want to start doing any of these things.
Jeff Terrell: Especially once you get your walking skeleton done you'll get into more of a natural rhythm of just working on features at that point so some of these things might start to make more sense at that point.
Jeff Terrell: Okay let's do a poll.
Jeff Terrell: Remember, I said I really want everybody to be present in person for the midterm next week that'll be Monday and Wednesday.
Jeff Terrell: So I just want to check to see if you expect to be available or if you're already anticipating complications with that.
Jeff Terrell: Okay.
Jeff Terrell: Okay, it looks like vast majority are of you're okay with showing up in person, I will read all of your responses to the other later not going to spend less time on that.
Jeff Terrell: But thank you for that information.
Jeff Terrell: whoops I keep forgetting that deactivates when I do that so.
Jeff Terrell: reactivate that okay i'm gonna keep moving.
Jeff Terrell: Okay, now I wanted to supplement those xp practices for agility with some others that either I have personally found useful in projects that i've worked on.
Jeff Terrell: And or ones that I think are fairly common in industry, these days, that might be worth knowing about.
Jeff Terrell: And, before I do that, let me tell you a story.
Jeff Terrell: About a guy named steady stand.
Jeff Terrell: ups.
Jeff Terrell: And unfortunately my notes are a little bit cut off wait, I can do this okay.
Jeff Terrell: So Stan graduated from college in 1967 years ago.
Jeff Terrell: He was.
Jeff Terrell: He got a degree in applied math.
Jeff Terrell: This is kind of before computer science was really on the radar of most universities.
Jeff Terrell: But he actually really left the Program.
Jeff Terrell: He spent a lot of time in the computer room on campus you know.
Jeff Terrell: figuring out his punch cards and caring as punch cards over to the operator to to run as programs and looking at the printouts for the output.
Jeff Terrell: And at some point you discovered fortran and really enjoyed fortran it's a great language it's a lot easier than all that Assembly stuff.
Jeff Terrell: And this is a pretty marketable skill when he graduated a lot of companies, wanted to hire him and he actually ended a pretty nice job at a large corporation, who is doing some computer work.
Jeff Terrell: And he really enjoyed it you got to do fortran all day every day it was great they mostly left him alone didn't make him go to a lot of meetings and he could just kind of sit in a cubicle all day and right program right programs, which you love to do.
Jeff Terrell: And he was real productive there, and he liked you know they paid him well, he was happy.
Jeff Terrell: As manager would say that stands a machine, he would just knock out that code day in, day out, he was rarely sick he always showed up and got a lot of work done.
Jeff Terrell: Some years pass and.
Jeff Terrell: status had various opportunities to try to branch out and learn new things.
Jeff Terrell: there's been this newer programming language called see that a lot of people are talking about.
Jeff Terrell: But.
Jeff Terrell: he's not really interested he's he's in his own groove he's getting good work done he's getting paid well he's happy he knows he knows fortran he likes doing that.
Jeff Terrell: Over time, more years pass and fortran becomes less important to the company that the market for fortran programs is just not what it used to be.
Jeff Terrell: And it gets a little bit harder for the company to find work for Stan that he actually wants to do.
Jeff Terrell: And there's been a few conversations that his manager has had with Stan to try to tell them.
Jeff Terrell: You know I really think it'd be better for you, if you tried to branch out a little bit maybe learn see maybe even learn Java, that seems to be the latest thing on the horizon.
Jeff Terrell: Think you'd be better off if you stepped away from fortran and started learning new things stand as I want to learn new things he sees in a groove he likes that work he does the same thing, day in and day out it's good.
Jeff Terrell: And he starts to feel pressure to change and even starts to feel kind of resentful about it, like.
Jeff Terrell: don't I do good work, why aren't they valuing the work I do I work hard and i'm just consistent i'm faithful i'm loyal.
Jeff Terrell: Productive i'm smart and they don't seem to like what i'm doing and what's changed why don't they like me anymore.
Jeff Terrell: A few more years pass and at this point that company has decided to completely abandoned fortran there's just no more market for it it's really hard to make money with fortran these days and there's no more room for Stan and the company I let him go.
Jeff Terrell: he's been offered many times to try to change what he does he's not interested in, so they let them go.
Jeff Terrell: And now Stan is 55 years old.
Jeff Terrell: And not many people are super interested in hiring a 55 year olds who they have to pay quite a bit compared to a 22 year old, who they can mold and shape, who is eager to start on new challenging problems and they don't have to pay as much and just got out of college and.
Jeff Terrell: So Stan has a hard enough time just based on that age gap, let alone the fact that he only knows for trends that's, the only thing on his resume he's darn good at it.
Jeff Terrell: And now, many people want a fortran programmer especially an aging one.
Jeff Terrell: So that's a sad story of studies Stan.
Jeff Terrell: What are some things that we can learn from Stan story what are, maybe some questions that.
Jeff Terrell: Maybe we could ask Stan or ask ourselves to avoid becoming study Stan.
Jeff Terrell: This is something, by the way, that I was a little bit worried about when I came on, as you can see, I was thinking like.
Jeff Terrell: Okay, I know as a professor i'm probably going to have to spend a lot of my time teaching and if i'm not careful i'm going to become more and more out of touch as time goes on, with what the latest technologies are and thankfully I don't think that has happened, but.
Jeff Terrell: that that was a risk that I saw.
Jeff Terrell: Let me tell you kind of what I see yeah Max.
Jeff Terrell: yeah yeah keeping in touch with what people are doing being willing to learn new things and grow yeah that's exactly.
Jeff Terrell: That was the first thing I had in fact definitely agree.
Jeff Terrell: And one student sent me a I guess a direct message it says we could keep asking how do we keep ourselves marketable yeah absolutely.
Jeff Terrell: Absolutely.
Jeff Terrell: Any other ideas.
Jeff Terrell: Max.
Jeff Terrell: Try different companies yeah a different company every three to five years that's I think that can definitely help i'm I have personally mixed feelings about that, like I kind of wish there were more.
Jeff Terrell: Like loyalty to companies, so there wasn't quite as much change happening all the time, and that makes you know it's hard to leave your teammates in the lurch when when you leave but but no, I think, for career advice that that is typically good advice is to keep things fresh.
Jeff Terrell: that'll help you stay current and so always having to kind of learn and be a beginner.
Jeff Terrell: So I don't think that's a bad idea at all, I just have mixed feelings about it.
Jeff Terrell: yeah so the this first thing I had written down, it was like recognize that our field changes quickly like far quicker than most right, I mean this is a really dynamic field it's a pretty young field.
Jeff Terrell: And there's a lot of things that we're still figuring out and that just aren't very mature yet.
Jeff Terrell: You know there's always a perennial debate about licensing for software developers, should we be licensed like plumbers and electricians and tradesmen are.
Jeff Terrell: And so far, the we haven't had to be but there's kind of a question of like well what if.
Jeff Terrell: Somebody wrote some code that was kind of low quality and it got hacked and it turned into something that really cost a lot of people, a lot of money, like shouldn't the programmers be accountable for that I don't know.
Jeff Terrell: So anyway, our field is young enough that we don't have any sort of licensing requirements, maybe that's on the way, maybe not but anyway there's value in just staying current with that just as Max said, like.
Jeff Terrell: keep learning keep growing try to stay current read hacker news.
Jeff Terrell: Another thing I thought about is, do we understand the value that we provide to the company.
Jeff Terrell: Do I understand my value to the department, just to make it personal.
Jeff Terrell: You know.
Jeff Terrell: Or if i'm working in a software shop do I understand my value to the client, even though maybe I don't actually talk with the client.
Jeff Terrell: Do I understand how i'm part of that overall picture and how i'm i'm in that context somewhere.
Jeff Terrell: Saying same question for the users what's my value to users.
Jeff Terrell: And you know, do I care what my value is or you know I think one of the mistakes that Stan made was he didn't really seem to care to understand any of that stuff you just wanted to program leave me alone, let me, let me write some code.
Jeff Terrell: And that worked for him for a while, but eventually.
Jeff Terrell: He will he would never was in touch you didn't lose touch you never was in touch with his value to the company and people who are thinking that way tend to be less valuable to companies and so when a company has hard times guess who's first on the chopping block right.
Jeff Terrell: You haven't really spent time thinking about your value to the company.
Jeff Terrell: And or maximizing that are trying to improve that so yeah.
Jeff Terrell: Lastly, how do we uncover when something isn't going well, or could be better.
Jeff Terrell: You know what if our value to the company isn't as high as it could be, how do we know how do we find that out.
Jeff Terrell: If we wait for that information to come to us by then it might be too late.
Jeff Terrell: It might be our manager telling us pulling us aside and saying listen i've gotta let you go we're in hard times, and you know I gotta let you go.
Jeff Terrell: By then it might be too late.
Jeff Terrell: So some of this is mindset which is foundational i've been distinguishing a little bit between the mindset of agility and the practices of agility and a lot of what i'm talking about here is the mindset of.
Jeff Terrell: Just staying fresh and understanding our value and things like that, but there's also particular practice that will help with this, and so I want to talk about one practice in particular that I think can help get at this, which is retrospectives.
Jeff Terrell: Anybody do a retrospective in a in a project.
Jeff Terrell: one.
Jeff Terrell: Okay yeah somebody online good.
Jeff Terrell: Today did it with your mentor fantastic fantastic, by the way, was it your idea or was it the mentors idea.
Jeff Terrell: His idea okay.
Jeff Terrell: Good mentor.
Jeff Terrell: Max.
Jeff Terrell: yeah right, you have to be one of those old companies that has a lot of old code and.
Jeff Terrell: yeah there's a big demand for cobalt programmers around the turn of the century, nobody knew that code anymore, and they were worried about Y2K bugs yeah maybe he'll find a niche like that maybe there will be happy and for steady Stan after all.
Jeff Terrell: Right let's talk about retrospectives this can help you not get stuck in a rut to understand your value to the company to get good feedback etc so.
Jeff Terrell: The basic idea, this is you sit down with your team, or maybe with your manager and you say first of all, what went well alright let's start listing out things that have gone well over the past X number of days or weeks or whatever.
Jeff Terrell: And you also asked what didn't go out.
Jeff Terrell: pretty simple just set up a couple of questions and just brainstorming different things that didn't go well, it did not go well.
Jeff Terrell: You can do this in parallel if you've got a team, even a relatively large team it's fairly easy to do this in parallel on a Google Doc you can also use this tool called easy retro.
Jeff Terrell: i'll leave that there for now, but and that that'll actually let you do it anonymously as well.
Jeff Terrell: I think.
Jeff Terrell: And then, if there's a lot of topics, you can just vote on 123 to focus on and dissect.
Jeff Terrell: stuff that went well, you can dissect to, especially if it's not obvious what the root causes.
Jeff Terrell: Try to figure out what the root causes, you might say, Okay, we seem to have a really productive iteration last time, why was that let's try to dissect that and figure out what the reasons for that were so that we can try to repeat that success next time.
Jeff Terrell: And for bad things understanding the root cause can help you avoid that problem in the future, of course.
Jeff Terrell: Now you can do this among the team that probably be the first place i'd recommend that you try it, but you can also do it with your client.
Jeff Terrell: You could talk to your client and say you know from your perspective, what went well what didn't go well, and can we dig into one one or two of these things to understand it better.
Jeff Terrell: This can help you collaborate more effectively to hone your communication skills.
Jeff Terrell: And just improve right, you can uncover surface problems and start to work on addressing those things once you know about them.
Jeff Terrell: You can do this with your mentor either about the mentor relationship itself and the mentor meetings or you could do it sort of among the development team, but inviting your mentor to add his or her thoughts and maybe even.
Jeff Terrell: guide you in the process of doing a retrospective.
Jeff Terrell: Most mentors have done retrospectives, by the way, some of them even do them pretty regularly.
Jeff Terrell: This is all over the xp values requires communication.
Jeff Terrell: And feedback, it requires some courage to be able to get into what didn't go well right.
Jeff Terrell: That can be a scary thing the idea here is to be candid but not to be mean right be respectful.
Jeff Terrell: Doing this can really build respect among a team can really build trust you really feel closer to people when you're actually starting to talk about problems in the relationship or the work relationship or whatever.
Jeff Terrell: and especially kind of hearing some of these things, but actually having a positive interaction around those things that's that's great builds respect builds trust.
Jeff Terrell: I recommend doing this at the end of each iteration.
Jeff Terrell: We talked about in an agile approach you're not trying to predict the entire project or just trying to predict one step at a time.
Jeff Terrell: And each step is called an iteration maybe it lasts a couple of weeks so every time you take one of those steps reflect on the previous step do a retrospective try to understand.
Jeff Terrell: What you want to keep doing and reproduce those successes and what you want to stop doing that didn't go so well.
Jeff Terrell: Practice number eight while we're on the topic of iterations I want to talk about client meetings y'all have met with your clients, a number of times at this point.
Jeff Terrell: But what I haven't really done up to this point is equip you very well for like what the typical sort of regular iteration meeting with your client might be like.
Jeff Terrell: And how to run a good client meeting, I guess, I did equip you to gather desert desert radha from your client, but just the typical sort of individuation meeting let's talk about that.
Jeff Terrell: really good idea to not just tell your client what you did but show them.
Jeff Terrell: Show don't tell that's.
Jeff Terrell: good advice for writing also good advice for client meetings.
Jeff Terrell: Show them, you can one thing that's nice to have like if you have a trailer board, you can have a column that says to review with client right just any card that has gotten done but hasn't been shown to a client yet can be collected there.
Jeff Terrell: And then, when you have a client meeting you can just walk through that list and for each one of those cards in the list.
Jeff Terrell: You can go to the web APP ideally the production web APP or maybe a staging web APP but something that's deployed where the client can actually access that APP and show them that future live in the APP.
Jeff Terrell: And then they could even go, either in the meeting or offline afterwards and play around with that future to get a better feel for it, or maybe to show you know other stakeholders in their company.
Jeff Terrell: Of course you'd like to invite feedback from the client, you know how's it look same thing look off, would you change anything.
Jeff Terrell: One thing it's really fun when it happens, and if you do this kind of thing in a client meeting it happens fairly often is.
Jeff Terrell: You can sense the excitement coming off of them you show them that feature like Oh, this is so cool and they're seeing you know they're they're seeing it takes shape and they get excited and they're like.
Jeff Terrell: You know, be really cool is if we could do this and man, I mean it's just fun to just feel that excitement, you know, and you felt like you actually contributed to that in a really real way but.
Jeff Terrell: But when they start saying like you know it'd be really cool as if you know we did this other thing that's something that they hadn't even thought of until they saw.
Jeff Terrell: The work that you've done right this happens all the time, this goes back to my point about.
Jeff Terrell: Your you can't expect your client to understand in perfect detail what they want, at the outset they're going to discover this.
Jeff Terrell: You know koalas to the Max you're going to have this progressive unfolding realization of what they want, and these client meetings are a great time for that to happen as you're showing them new features.
Jeff Terrell: And, of course, this is when you're doing your planning for the next step of the project and so you're trying to figure out, what are the priorities to the client, the thing you're trying to maximize is valued deliver to the client.
Jeff Terrell: you're not trying to achieve perfection of the APP or anything like that you're just trying to give as much value to your clients, as you can.
Jeff Terrell: And a major input to that function is what is the client want the most right what are their priorities and that might change a bit from week to week but being able to plan that for the next step and get the in the clients input, for that is pretty important.
Jeff Terrell: Now, an input to priorities, this can actually be how much effort, it will be to implement these various things.
Jeff Terrell: For the development team, so the client might say, for example, the top priority is a.
Jeff Terrell: And the development team looks at and says we could do a but that's pretty much going to be the only thing that we can work on this iteration.
Jeff Terrell: But if you wanted us to work on other things we could get be through F knocked out instead of a if you, you know if that was more important to you.
Jeff Terrell: And with a choice like that the client can say well actually yeah I want a the most of all, of any one thing, but.
Jeff Terrell: If I have to compare that one thing that these five other things and yeah give me the five other things.
Jeff Terrell: So if you can give them estimates about effort that can really help them understand have kind of an informed view of their priorities.
Jeff Terrell: And again, it might be useful to have a retrospective with the client.
Jeff Terrell: question about meetings.
Jeff Terrell: client meetings.
Jeff Terrell: Okay.
Jeff Terrell: Two more practices.
Jeff Terrell: One show value early and often i'm going to kind of skim through this the idea here is trying to deliver value to your client as much as possible as quickly as possible is really important.
Jeff Terrell: So convey value to the client as soon as possible, helps build trust.
Jeff Terrell: Getting a clickable prototype in their hands as quickly as you possibly can, as really effective same thing with a walking skeleton after that.
Jeff Terrell: I actually do this when I do freelance work, you know I do freelance work like in the summers and stuff yeah I mean I, this is one of the great things about my job is that.
Jeff Terrell: summer has my own time, I can do whatever I want with them don't have any responsibilities for this job so a lot of times i'll take on some freelance work and.
Jeff Terrell: This is something I do I try to get that clickable prototype to them as quickly as I can.
Jeff Terrell: or kind of walk me skeleton after that and by them they're hooked right, I mean they don't maybe they're not quite sure that i'm the right fit or whatever, but.
Jeff Terrell: I start doing this stuff they're like Okay, you know what you're doing I feel like you've already delivered so much value just in the short time when we started.
Jeff Terrell: run with it go, you know I trust you now.
Jeff Terrell: And yeah that's one reason why i'm making you go through the pain of the walking skeleton right now, yes I think it's good I think it's really worth knowing how to do that.
Jeff Terrell: really helps build trust with your clients both this one this semester, and any future clients, that you have.
Jeff Terrell: Okay number 10 so estimation.
Jeff Terrell: i'm gonna see class ends at 240 right yeah we don't have much time i'm going to come back to this one next time I want to skip ahead to.
Jeff Terrell: I was pretty close to the end, but.
Jeff Terrell: Quick mentorship try to do a team retrospective and your mentor meeting, if your team's cool with that and, especially, if your.
Jeff Terrell: Your mentor is probably going to be cool with that that could be a really nice way for them to coach you on how to run a retrospective but also they might have some good feedback for you.
Jeff Terrell: So just an idea for something to do with your mentor.
Jeff Terrell: last thing is a poll so let's go to this is just takeaway questions and when you're finished with these you can go thanks a lot i'll see you all on Wednesday.