As we go into the job of building we're principally going to be talking about practices from XP because, as I mentioned earlier, XP has prescriptions and practices for the activities of building software. Where as scrum mostly deals with the process of managing the software team. Here are a few practices in this area from XP. Let's go through them, talk about why they are useful to the job of building, and whether or not they might be something that's interesting to your team. So the first is Pair Programming. And the idea here is that two developers work together to build, instead of just one. One is generally typing and actually writing the software and the other one is advising them and discussing implementation with them. Now, you may have heard Spotify say well we do code reviews, peer code reviews. They didn't explicitly mention peer programming, although from what they said those teams would be free to do that if they wanted to. And that's probably a good model. I am not a career developer, so at best I'm an enthusiastic tinkerer. When I want to know something about the state of practice in an area like this, I talk to friends and colleagues and I ask them, for instance, what is it that you get out of pair programming that you don't get out of pair negotiation and discussion before the fact or peer code reviews after the fact? Generally, what they tell me is that there's so many little decision that go into making a piece of software. Which is absolutely true, and those little decisions end up being so important which they are. And by having somebody right there with me while I'm working, I'm able to get consultation, and make better decisions and stay more focused than I am if it's just before and after the fact. That may or may not be the case for you and your team, but that is what I would say is probably the number one general virtue of this. Let's talk about how this works in practice with a house metaphor. Now, a software is not a house, it has many more points of freedom about how you approach it and those end up having really big implications for how the software performs. How it makes itself amenable or not amenable to change and how it delivers for the user. So there are limits to this, but for a simple explanation, I think it's pretty useful. So let's say Steve and Dave are digging the foundation for a house that they're going to build. So Steve is actually doing the digging. And Dave is his pair and is helping him. So, for instance, in this very simplified metaphor, Steve's in there doing the real work, and Dave's helping to make sure that he doesn't go off track. That he stays focused, answer questions about how to do the digging and maybe Dave is off getting supports and handing things to Steve that he needs. And so on a very simplified basis you can see how even in the house metaphor which is vastly simpler and more consistent than building software, this might be handy. Steve maybe gets down there and loses track of what he's doing. Dave has the idea of what should be done. This is the general idea with pair programming that Dave is able to help Steve make better decisions and stay on track. And then there's a few less obvious things, for example, maybe Dave is the Senior Developer or has been on the team a long time. And he's helping Steve understand their conventions and approaches to things. So at a really high level, that's generally how this works and why some teams find this useful. There's another practice here, let's talk about that. Test-First Programming, the idea here is that as a developer is working they write unit tests, and these are individual tests that go into some kind of automation suite. So once you write them you can run them every single time to make sure the code is okay, and these serve to avoid low level bugs, and as it says here they happen first. So before the developer even starts writing code, they write unit tests that will validate its functionality. Now, the reason why that's helpful is, there's a few reasons. One is obviously, it helps avoid bugs, it catches them before they flow out into the overall build and people are trying to test the overall software and then re-trace it back to what went wrong. Another reason is that it serves as a kind of encapsulated documentation about what the code should do for another developer that has to come and debug or extend or maybe wants to reuse this piece of code. And then I think if you talk to a developer that does this, some will say that it helps them focus and think about how they're going approach writing the code, whatever it is, a function, class, item, so forth. So XP recommends doing this any many developers that you may talk to will say this is sort of their default position is to do it versus not do it. And then there are also detractors that find that it generates a lot of waste. They have to do things that they wouldn't otherwise do to make good unit tests and they feel like it does more harm than good. So it's not to say that this absolute should be done it's always the right thing. Another thing that I think you'll hear is that if it's mandated to a team that doesn't have any support forward or experience with it which will be a terrible idea to do. Then it's not going to go well because it takes experience and training to get comfortable doing this and know what's a good kind of test versus what's overly elaborated and isn't going to work well. In our house metaphor, there's a few things that unit testing gives you, but let's say that we use the wrong kind of nails on our house. And when it finally rains, the house is leaking. And there are people in the house living there now, and it's a bummer. It's going to take a lot more trouble to fix these nails now than it would've early on if somehow we had a magical way to make sure that as every nail went into the house, it was actually okay. On a very oversimplified basis, that's the general idea with test-driven development is that it helps us focus, validate what we're going to do and then it serves downstream as a source of documentation, understanding about what this piece of code is intended to do. And it helps us avoid errors going downstream, where they're more expensive to fix. Let's talk about this idea of incremental design. This is maybe one of the more nuanced ideas, and the idea here is that rather than building code structures that anticipate future use of the code, and the ability to reuse parts of a code framework. That, instead, we just solve the immediate problem that we know we need to do on a highly decoupled modular basis. You heard Spotify talk about the importance of decoupled functions. And the fact that they avoid hand-offs like the plague. So incremental design and decoupled software components help you get this. The idea is that by solving the immediate problems that you have, and making slack time to refactor these things as you actually see what the code needs to do, a better design will emerge from this practice than you ever could have created if you just tried to anticipate it before the fact. Now, maybe this sounds a little bit similar to some of the things we've talked about in course one and two. For instance the fact that we'll tend to want to write a big, long elaborate business or operating plan to give us a sense of certainty, where in fact we really don't and can't possibly know enough to actually do that. In a lot of ways that has some kind of analogs for the assumptions and the ideas behind incremental design. That it's impossible to anticipate exactly what you're going to want a code to do. So solve the problem you have, make it very modular so there isn't a whole bunch of dependencies that will make it hard to change it in the future and use it in the future and you'll be much better off. This one's maybe a little bit harder to map to our building metaphor but there is something that might be kind of interesting. One of my favorite books of all time is How Buildings Learn by Stewart Brand. And one of the things that he found was that some of the most beloved buildings are extremely simple. They're nice sound structures, but the architects and the people who built these buliding's just built them so they could be very flexible. Walls could be changed around, wiring and other services like plumbing are easy to get in and change around in the building. And that these are the most favorite buildings. Where on the flip side, buildings where the architects thought that they had mapped out each little thing that the builders of the building would want and they were very tightly constructed and hard to change. Those were some of the most hated buildings. Now, that doesn't map correctly to software code, but it has some of the same principles, the idea that it's better to build a nice solid thing that can be changed at the levels that we may need to change it and change it over time in the future, and yet remain nice and solid. That's kind of analogous to some of the assumptions behind incremental design. So we'll take a little pause there and in the next video we're going to talk about some of the integration practices and testing practices, system testing practices from XP.
