1<html> 2<title>Schedule Rationale</title> 3<body> 4<h1>Schedule Rationale</h1> 5Below is an informal discussion of the rationale behind the Interface Kit team's 6behemoth schedule. Various details may not reflect the current form of the schedule, 7but the basic gist is what's really important here. 8<br> 9<hr> 10<p> 11First, let me head off the suggestion that we formally split into 3 or 4 stand-alone 12projects: the Interface Kit, Application Kit and app_server are completely 13dependent on one another in a way that no other set of system components is. Each 14without the others can accomplish almost *nothing*; I think the existence of Integration 15highlights this fact. 16</p><p> 17Each milestone listed has a number of tasks associated with it; these need to be listed 18and the time for each estimated. These tasks should be as fine grained as possible. 19Taking BView as an example, I would expect each method on BView to have its own entry 20under milestones 1, 2, 3, 4 and 8 with entries added as necessary to milestones 18 to 2122. "Why so detailed?" you say. I'm glad you asked. ;) 22</p><p> 23First off, the finer the schedule's granularity, the more realistic estimate you have for 24the project as a whole. Asked to implement BView, one might be tempted to say "Oh, about 253 weeks," whereas an estimate of the time needed for each method might yield a total of 26two to three times that. While the more realistic overall estimate may be more depressing 27initially, being able to hit goals on or near the estimated date is much better for 28morale in the long run than constantly being behind because all the estimates were too 29low. Trust me on this, I've worked on *way* too many projects that went south because of 30scheduling that was too broad -- usually because the project manager doesn't want to 31"distress" the client by making them pay for the time to schedule correctly. Or design 32correctly, but that's a different rant. =) 33</p><p> 34Second, a fine-grained schedule helps to ensure that nothing gets missed. You might 35think it would be hard to forget to implement a BView method, but if you don't expressly 36schedule for that method, there will be no interface, use case or technical specifications 37or unit tests to fail because the method isn't doing anything. In fact, we might not 38notice the missing functionality until some app that uses it dies a horrible death and 39we have to figure out why. 40</p><p> 41Third, it helps us figure out what functionality is dependent on what -- which helps us 42schedule our tasks in a logical sequence. 43</p><p> 44Fourth, it makes it much easier for someone that doesn't have a lot of time available or 45much experience to pick something that they can tackle and know that they will be making 46a meaningful contribution. It also makes it easier for us to keep track of who is doing 47what on large items like BView: instead of saying "there's a bunch of stuff on BView 48that needs doing," we can say "BView::StrokeEllipse() needs to be implemented" and know 49that a specific person is responsible for that deliverable. 50</p><p> 51Fifth, as daunting as a detailed schedule looks like out of the gate, tasks are getting 52completed *constantly* and it's very satisfying to see progress get made on a regular 53basis. Ideally, one would like to be able to check on the progress each week and find 54several items completed since the last time it was checked. 55</p> 56<hr> 57 58<!-- The obligatory SourceForge plug --> 59<center> 60<small>The OpenBeOS project is hosted by:</small><br><br> 61<a href="http://sourceforge.net"> 62<img src="http://sourceforge.net/sflogo.php?group_id=33869&type=1" width="88" height="31" border="0" alt="SourceForge Logo"> 63</a> 64<p> 65 66<small>Copyright © 2001-2002 67<a href="http://www.openbeos.org">OpenBeOS</a> Project</small> 68</center> 69 70</body> 71</html>