James Carlson wrote: > Roland Mainz writes: > > > You're not > > > really planning a project with dozens of pushes, each with its own RTI > > > review, code review, design review, and testing, are you? > > > > No no no. The problem is that I try to avoid the "90%/10% trap" where > > 90% of the code works and the remaining 10% causing months of delays. > > Instead of hitting this trap I try to split the project into "chunks" > > and when 90% of the chunks are running perfectly do a putback (keeping > > the "not perfectly running 10% chunks" disabled by default) and then > > work on the remaining 10% in "peace". > > The idea is to reduce the number of ARC cases to exactly one but still > > being able to deliver most of the results _quickly_ and the laggards > > with a 2nd+3rd putback (which means only two or three putbacks total). > > I think the option you're looking for is "fast-track."
Ok... but that would mean we have the code ready _before_ the ARC case (technically that's again the case for ksh93-integration update2 since update1 took that long... ;-/ ) ... and if the ARC case changes or rips-out things then we spend again major work to adjust the code. Somehow I hope to get the following ordering: 1. Get raw prototype 2. ARC case fasttrack 3. Do main coding/testing work 4. Deliver code if we reach the 90% barrier 5. Do more coding work to cover the remaining 10% 6. Putback the remaining parts once they are ready > Given the scenario you describe, I would describe the project as a > single deliverable (or a simple series of two deliverables, if that > makes sense), and leave out all of the parallel tasks with > dependencies. > > *IF* I later ran into a task that was troublesome, and it looked like > that one task would cause unacceptable damage to the schedule, and if > the task could actually be delivered later without harm to the > project or the users, then: > > a. If the original case had already been approved, then I'd then > file a fast-track to amend that case, describing what I was > going to deliver separately, the impact of this change, and any > resulting changes. That's what we did for ksh93-ingration update1 multiple times and we still needed 15 months. Somehow I'd like to get the "unpredictable" parts moved to the beginning or having them "disarmed" that they can't interfer with the project schedule anymore. > or: > > b. If the original case had not yet been approved, then I'd note > the changes as part of my commitment materials. > > Why introduce extra complexity to deal with something that's only > speculative, and that really ought not be that bad anyway? > > I suspect you're making this much harder than it really needs to be, > and that you might be doing so based on an assumption that the ARC > can't handle changes. We're just working peer engineers, not the > local zoning board. What is a "zoning board" ? ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;)
