[MUSIC] Right, so we've got this general idea of how this application development process is going to work. And the idea, so rapid prototyping, and user testing, and so on. But, what we're gonna give you now, our sort of proposed way of dealing with the question of time management. So, how do you monitor how much time you're spending on things? How do you make sure that things are getting done? And so, on. So, what kind of process, James, who's joining me from Goldsmiths College again, would you recommend to really make sure that we can keep a track of what we're doing and whether it's working, okay. >> Well, it's really important to have good time management. I mean, the thing is, most projects got overrun. Cost more than they should and fail to be delivered on time due to poor time management. So, there are lots of different ways. Obviously, at the beginning of your project, it's useful to take the digitized idea, we talked about earlier, and translate it into a project plan. >> So, the digitized idea, if you'll remember, sort of results in a prioritized list of processes that a user can go through, right. So, we've got high level, important processes at the top of the priority list, and then, lower level processes below that. And that can be turned into a project plan, can't it? >> Absolutely. So, we can have project plan which identifies the milestones at which these various processes will be implemented. So, yes. So, that's a really, really useful thing. But if you remember, we talked a lot about round, and round you go prototyping. And so, your testing, and your time management should fit with that model. So, I would suggest that you identify a week or a bi-weekly schedule of works. >> Right so, what's a biweekly schedule that works? >> Right, so what you do is you identify the task that you're going to try, and achieve in the next week or two weeks, whichever you prefer. And you identify each of the tasks, how long they're going to take, and what resources of effort you need to do them. >> So, at the beginning of the week, I'm writing this description of what I'm going to do in that slice of time. >> Absolutely. >> Right. >> And that's very, very important. And that way, every two weeks you can see what progress you've made, what progress you haven't made. The other thing that I think is quite important is what we would call a weekly review. Now you can do that any way you like. However, I would suggest it has three components, the first of which is, what went well? It's very important to identify, and celebrate your successes in programming. What did you do well? But it's also important to know what went badly. What went wrong, what did you have to spend more time on then you shouldn't have. >> So, what did you get stuck for six hours trying to find the semicolon [CROSSTALK] >> Absolutely. >> And was the semicolon really necessary. >> Yeah, knowing java script. >> Absolutely. Sometimes programmers, and I've been guilty of this myself, will spend a lot of time on something that functionally isn't very high up that target list. And so, we've gotta always be wary of that. Is that really the most important thing to do with that little cycle that we've identified? So, it's what went well, what went badly, and finally, what have we learned. So, that weekly review as long as it has roughly that structure is a good thing. The final thing that I think is always use for program is to have, is a development diary. >> Okay, and I guess all of this stuff can go into the development diary can't it? So, it's almost a place where we store all this. >> Absolutely. So, the development diary is a place where we store this, but we also store are important things that we've discovered, or milestones we've reached. So, if we found a new package that we think is gonna be useful later on, we put that in the development diary. If we found a way of working with a database, and we created some new tables, or some new relationships, put it in the development diary. If we reached a milestone, in the project's development, put it in the development diary. And that's the idea. >> And so, also with this, what went well, what went badly, and so on. The reflective part. We should be looking at that, when we're deciding what we're going to do in the next section, right? >> Absolutely. >> Sort of where were are our problems, and that will allow us to, as the project progresses, we get better, and better at setting ourselves realistic tasks for that week. >> Do you remember those three steps we talked about in implementation? >> What were they? >> They were to design, implement, and review. And that's what you'd also be doing, and reflecting in that diary, and in that review. So, as part of your time management, you wanna say, okay, what did we design? How long did we say it would take? What did we implement? How long did we say, it would take? And then, review them. >> Okay, great. So, that's just giving you some sort of ideas to think about, and actually, a very clear process which we would like you to follow in the development of your projects. And so, part of the assessment is gonna be based on you having correctly followed that process. So, thanks a lot James, that's really given them a nice concrete way of working through their projects. >> Brilliant. >> [MUSIC]
