news:comp.object just keeps begin' for that evangelist spirit:

On Tue, 4 Sep 2001 17:18:42 -0400, "John A. Byerly"
<jbyerly@ess-quality_remove.com> wrote:

 >Now that the dream is over, here is how it usually takes place.  We step out
 >along the dream path, then some manager figures out that eliminating code 
 >reviews would shorten the schedule by 3 weeks, and eliminating design
 >reviews would save another 3 weeks.  With the reviews gone, and with
 >schedule pressures mounting, half the developers decide that they can just
 >start coding, and to heck with this design stuff (they didn't really
 >understand it anyway).  Finally, enough code is written to start
 >integrating.  Except, I didn't realize that we were using callbacks.  I used
 >the Observer pattern instead.  After all, we agreed that I would be
 >notified, I guess we really never settled on how.  And so on.
 >
 >What usually happens is that the schedule is shortenend on paper (which is
 >what counts to the managers) but is increased many times in actuality during
 >integration and test.  Then the course of action is to start cutting out
 >features so the delivery schedule (the third re-estimate, not the original)
 >can be met.
 >
 >You know, this would all be rather humorous if it weren't true.

It answers it very well, thank you.  In essense you are saying that
you work in a typical organization.  That you wish you could do lots
of up-front work, but that you're organization doesn't have the
patience to let you do it.  They seem to be driven more by dates than
by rational thought.  No wonder you wish you had time to do the
analysis and design up front.

Let me paint you a different story.

Every TwoWeeks you and your team deliver new features to your
business. They get to choose which new features they are; and you get
to tell them how many new features you can do in two weeks.  They see
progress every two weeks.  Not only that, its the progress that they
want to see. 

[ProjectVelocity, UserStories]

The schedule belongs to your managers.  They see how much you get done
every two weeks; and they order the features such that you get the
most important things done first.  

[PlanningGame, CustomerBillOfRights]

Each iteration you and your team work together in the same room.  You
work in pairs; and the pairs work three to a table.  Perhaps there are
two or even three tables in the room.  Every day the entire team meets
for thirty minutes to plan the day's activities.  If someone is going
to use an Observer, you're likely to find out about it at that
meeting.

[AllEngineersInOneRoom, PairProgramming]

Pairs switch off twice per day.  Over the course of two weeks,
everybody works with everyone else on everything.  Nobody owns any
particular module, everybody is reasonably familiar with the whole of
the code base.  

[PairPromiscuously, SharedCodeOwnership]

Integration occurs several times per day.  There is one code baseline
supported by a bevy of unit and acceptance tests.  Every couple of
hours each pair checks in their changes, makes any merges necessary,
and makes sure all the tests continue to pass.

[TestInfected, CodeUnitTestFirst, AcceptanceTest''''''s, ContinuousIntegration]

No integration woes, no "callbacks instead of Observer" woes,
continuous reviews, continuous design, managers who know the status of
the project in detail, and who manage the schedule by selecting
features.

[TestDrivenDesign]

--RobertCecilMartin

----

CategoryExtremeProgramming