[techtalk] XP vs UML

[Caitlin]

On Wednesday, March 28, 2001, at 10:39 AM, Shari wrote:

>
> Sorry if this is grossly off-topic or if its been covered...
>
> I was curious if anyone out there has any thoughts on this particular 
> topic.  I
> work for a consulting firm and we are attempting to turn ourselves into 
> a real
> UML shop, but when I think about it, most of our projects take the XP 
> approach
> (albeit accidentally!)
>
> I say this because more and more, I see our projects become 
> client/deadline
> driven.  The intial functionality we design gets stripped in order to 
> meet
> dates.  Part of me thinks, if we simplify from the very start, maybe we 
> can
> avoid this.  For example, code only the bare minimum functionality 
> needed;
> assume we can always add stuff later; don't create frameworks, etc.  I 
> do UML
> design models like crazy, but so much doesn't get implemented, it 
> almost doesn't
> seem worth it.  But on the other hand, shouldn't a clean framework save 
> you more
> time later?
>
> Any thoughts?  Does anyone actually use XP as a design approach?
>
>
> Shari
>

I'm firmly in the UML camp, but in the minimalist wing.

What I have seen repeatedly is hard-working market driven teams
digging themselves into deep holes by "rapidly" turning out code.

They "rapidly" turn out code that deals with the most obvious aspects
of the problem, but is structuraly at odds with the complete 
requirements.

They then "rapidly" pile on layer after layer of fixes and "exception
handling" until they have complete chaos.

XP hand waves around all of this by saying that you need a "strong
unifying metaphor". But exactly how are you supposed to get that?

People want me to be "brilliant" one providing that metaphor to
guide XP style development teams. But I rely on the rigors of
a methodology to check myself to make certain I have at last
spun consistent delusions.

English narratives and Visio diagrams are mush that fuzz over
the worst inconsistencies in the world. XP encourages reliance
on such tools -- and on the subjective judgement of the team
as to whether they have "done enough planning".

You must adapt your methodology to your market requirments.
For my current projects that means that I model how components
interact, but not how components are coded. Each market
situration may require a different answer.

But I always have determined in advance, what information I
have to have in the model for it to be complete, as least as
far as a given feature goes. There's a place in the model
for that information, if it is missing the model is not complete.

Period.

  XP is just the latest phrase for "wing it". Whiteboard engineering
and prototyping proceeded it. There are application domains where
none of the coding is innovative engineering, it is just making sure
you're combined the pieces in a way that satisfies the customer.
In *those* environments encouraging a rapid turnaround time
is essential, and RAD development makes sense.

The is also definitely on-topic. XP and its earlier excuses
for lack of a methodology all have great faith in the abilty
to make ad hoc judgements without any rigorous guidelines
to determine when you've though about something enough.

IMHO, most engineers are no more capable of making those
judgements without benefit of a methodology that includes
diagramming than they are of knowing when they need to
use a map or ask for directions.

Some humans, have this strange cultural compulsion that
says drive on when they should be admitting their lost.
XP seems to say "right on brother"