Home > Archive > Extreme Programming > March 2004 > Re: Second Dimension of Object Oriented Modelling
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Re: Second Dimension of Object Oriented Modelling
|
|
| Laurent Bossavit 2004-03-18, 6:53 pm |
| > experts in the software design arena seem to have developed a
> consensus around the fact that software ought to be developed
> iteratively. Now, the fact remains that a very good and experienced
> designer is going to see more of the problem and its solution than
> others would. Nevertheless, I have seen exceptional developers make
> fairly gross errors in judgement using the approach of up-front
> design.
See for instance Knuth's paper "The errors of TeX".
Laurent
http://bosssavit.com/thoughts/
| |
| Gawnsoft 2004-03-18, 6:53 pm |
| On Wed, 10 Mar 2004 16:14:43 GMT, JXStern <JXSternChangeX2R@gte.net>
wrote (more or less):
>In fact, I
>suspect Evans swings and misses the target here, much as you do. In
>the preface he says:
>
>"Developers and domain experts have a close relationship."
>
>No. The developer eats domain experts, becoming the domain expert,
>and then some.
Hmmm - an admirable goal, but not one I'm used to seeing played out in
the real world.
If it did happen as a matter of course, the number of
completed-but-left-unused systems in the world would be much smaller
than it is.
Cheers,
Euan
Gawnsoft: http://www.gawnsoft.co.sr
Symbian/Epoc wiki: http://html.dnsalias.net:1122
Smalltalk links (harvested from comp.lang.smalltalk) http://html.dnsalias.net/gawnsoft/smalltalk
| |
| Shayne Wissler 2004-03-18, 6:53 pm |
|
"Tsolak Petrosian" <tsolakp@yahoo.com> wrote in message
news:a052897d.0403102307.3e58e534@posting.google.com...
> "Cell have chromosomes, chromosomes have genes which in turn let the
> cell to
> send messages to other cells (using RNA strings) and clone or mutate."
Cells do not communicate with other cells by using RNA strings. The purpose
of DNA transcription into RNA sequences is to drive protein synthesis within
the cell itself.
> from which we can draw this conclusions:
From this I draw the same conclusion I already had: Understand the subject
on its own terms before trying to make metaphors. If one doesn't understand
biology, and one doesn't understand software, then trying to compare them
like this is only going to deepen the ignorance.
> Fundamental to biology is cooperative components (cells)
That is not fundamental to biology. Some biological systems are made of
cooperating cells. Some groups of cells are just individual cells.
> which can
> discover and cooperate by contract (sending message using RNA) with
> other components and create other types of components (cloning and
> mutation).
Nope.
> Which implies that fundamental to software is notion of component
> (like cell), its type or contract (in static languages its Class, in
> some its just plain message String) and creation of other type of
> components ("new" Class, clone() and prototype objects).
>
> This is the conclusion I am drawing from real world which helps me to
> pick the right path to design and understand that things like AOP and
> most of design patterns in GOF are helping artifacts and not
> fundamental concepts.
You need a new approach, this one isn't working.
Shayne Wissler
| |
| JXStern 2004-03-18, 6:53 pm |
| On Thu, 11 Mar 2004 03:18:31 +0000, Gawnsoft
<xlucid@users.sourceforge.remove.this.antispam.net> wrote:
>On Wed, 10 Mar 2004 16:14:43 GMT, JXStern <JXSternChangeX2R@gte.net>
>wrote (more or less):
>
>
>Hmmm - an admirable goal, but not one I'm used to seeing played out in
>the real world.
>
>If it did happen as a matter of course, the number of
>completed-but-left-unused systems in the world would be much smaller
>than it is.
Amen to that.
Just to be clear, what I mean is that the program becomes the expert,
with however many users depending on it for daily operations. The
developer better understand what the program does - and does NOT - do.
Usually a human expert knows tons of things that are outside the range
of the program, and typically special cases remain even inside the
range that the program mishandles but everyone works around. And
seldom does the developer go on to a career as human expert in the
domain - though he may become a human expert in systems about the
domain.
But, just as Evans disapproves of developers who pay little attention
to the domain model, I see this "developer and domain expert ...
relationship" as likely to preserve the problem, if the developer does
not internalize the issue a bit more than this sounds like.
Well, perhaps that's what Evans means (in part) by "model", I suppose
I should read the book.
J.
| |
| sirgilligan 2004-03-18, 6:53 pm |
| vladimir_levin@yahoo.ca (Vladimir Levin) wrote in message news:<88f5a83.0403101702.36d3f99a@posting.google.com>...
> sirgilligan@yahoo.com (sirgilligan) wrote in message news:<c1de56dc.0403100744.4e34a837@posting.google.com>...
>
> As far as I know, whether you are using Test Driven Development or
> not, whether you are in fact using Extreme Programming or not, most
> experts in the software design arena seem to have developed a
> consensus around the fact that software ought to be developed
> iteratively. Now, the fact remains that a very good and experienced
> designer is going to see more of the problem and its solution than
> others would. Nevertheless, I have seen exceptional developers make
> fairly gross errors in judgement using the approach of up-front
> design. A Grand Vision can be a dangerously seductive siren, and an
> empirical step-wise approach is an excellent preventative measure
> against this desease. I used to play a game called Go quite a bit when
> I was in university. I could tell when I played against stronger
> players how they could see so much more than I could; nevertheless, as
> the game went along, they were always flexible and willing to adjust
> their strategy to the current pattern on the board. My general sense
> of Go, and I believe this applies very nicely to software development,
> is that as one becomes a better player, one becomes /more/ willing to
> alter one's design in the face of changing requirements and
> priorities, not less.
Very well said. I have witnessed the same things in programming. I
have not played "GO", but I do play some serious Ping-Pong. When you
play someone that is a top-spin, smash it every time player you have
to adjust (usually put a side spin to his back hand). The short is,
you adjust to the situation to be successful. That is why I started
writing my memoirs (Maverick Dev Model, and Maverick Agile Method). I
am trying to get people to think. To understand why a method exists. I
can't remember the book, but someone said, "Most methodologies are the
answers to issues and problems we have faced." They do not represent
the development experiences that went well. So, I am learning a lot
from everyone's posts. I am saying, "Think. Use your head! Use the
full experience of your college curriculum. Use the full experience of
your life. Don't follow a methodology when you know or maybe just feel
that it is not going well. Prove to me that management really
contributes to software engineering. Prove to me that it takes as many
managers as I find in my company to actually provide the contributions
of management. Try to stop me from iterating in a waterfall method if
that is what I see needs to be done. Try to stop me from altering the
length of an iteration if I see it needs to be done. Try and stop me
from telling the truth about the status of the project when managers
don't want to hear it or say it."
Thank you for you comments, I will keep reading the thread and posting
my unpolished ideas. Maybe I do it because I feel a need to be heard
and maybe I just want someone to say, "that sounds right, that is a
good idea."
I am trying to catch up on some Web Services skills and I am doing
some extra coding/studying for a while and then I will try to finish
off all of the sections of Maverick. I highly recommend reading the
book:
Maverick: The success story behind the world's most unusual workplace.
Ricardo Semler. Warner Books. Copyright 1993.
Thanks,
Geoff
p.s. I am just sick today about Madrid and the bombings. I lived in
Spain for almost 2 years and I have been to Atocha station many many
times. This world is wearing me out.
| |
| Universe 2004-03-18, 6:53 pm |
|
"Shayne Wissler" <thalesNOSPAM000@yahoo.com> wrote in message
news:S404c.7000$i76.97218@attbi_s03...
>
> "Tsolak Petrosian" <tsolakp@yahoo.com> wrote in message
> news:a052897d.0403102307.3e58e534@posting.google.com...
>
>
> Cells do not communicate with other cells by using RNA strings. The
purpose
> of DNA transcription into RNA sequences is to drive protein synthesis
within
> the cell itself.
Strictly, yes, right, "messenger RNA".
But cells do "get around", don't they?
And some cells use RNA in the core in lieu of DNA-retroviruses like HIV.
Elliott
--
Model the World to Leverage Finely Honed Complex Systems!
--
We Don't Always Have to Nickel & Dime Our Way to Create Robust Complex
Systems.
| |
| Universe 2004-03-18, 6:53 pm |
|
"sirgilligan" <sirgilligan@yahoo.com> wrote in message
news:c1de56dc.0403110948.1cd9448a@posting.google.com...
> vladimir_levin@yahoo.ca (Vladimir Levin) wrote in message
news:<88f5a83.0403101702.36d3f99a@posting.google.com>...[color=darkred]
news:<c1de56dc.0403100744.4e34a837@posting.google.com>...[color=darkred]
And I've seen 'em design fantastic, workable, efficient, robust and reusable
mostly up-front.
[color=darkred]
Ditto, nickel and dime, fearful, time and resource wasting, super pragmatic,
baby stepping.
Elliott
--
The thing is that doing holistic investigation and creating
holistic plans at all times takes us as far ahead in terms of
understanding, as rapidly as possible while enabling us to
implement at all times in a way that supports what we
know will shortly be incorporated.
| |
| Tsolak Petrosian 2004-03-18, 6:53 pm |
| "Shayne Wissler" <thalesNOSPAM000@yahoo.com> wrote in message news:<S404c.7000$i76.97218@attbi_s03>...
> "Tsolak Petrosian" <tsolakp@yahoo.com> wrote in message
> news:a052897d.0403102307.3e58e534@posting.google.com...
>
>
> Cells do not communicate with other cells by using RNA strings. The purpose
> of DNA transcription into RNA sequences is to drive protein synthesis within
> the cell itself.
>
But protein made from RNA message is actually playing receptor role or
just interacting with environment.
Still good point, the fundamental concept here is not RNA message or
protein synthesis but a way of interacting/communicating with
environment (other cells and proteins).
>
> From this I draw the same conclusion I already had: Understand the subject
> on its own terms before trying to make metaphors. If one doesn't understand
> biology, and one doesn't understand software, then trying to compare them
> like this is only going to deepen the ignorance.
>
>
> That is not fundamental to biology. Some biological systems are made of
> cooperating cells. Some groups of cells are just individual cells.
>
Doesnt matter the important part is cooperation and communication.
Some component can be passive but most need to be active to make
system work.
>
> Nope.
>
>
> You need a new approach, this one isn't working.
>
>
> Shayne Wissler
In previous message I asked this question:
"If I may ask, what's your understanding of Classes and Objects"
for which you replied:
"That is a pretty general question. My understanding encompasses a lot
of
things; you'll have to be more specific."
But the answer simple is:
"Which implies that fundamental to software is notion of component
(like cell), its type or contract (in static languages its Class, in
some its just plain message String) and creation of other type of
components ("new" Class, clone() and prototype objects)."
Because since "software is as much subject to the laws of logic as is
anything else" then it needs to adhere to fundamental concept of logic
and real world patterns (since logic is driven from real world
patterns).
Tsolak Petrosian
| |
| Gawnsoft 2004-03-18, 6:53 pm |
| On Thu, 11 Mar 2004 16:07:07 GMT, JXStern <JXSternChangeX2R@gte.net>
wrote (more or less):
>what I mean is that the program becomes the expert,
>with however many users depending on it for daily operations.
And my contention is that most times, the program ends up embodying
the problem domain expertise of the designers and developers, which is
often much less expert, comprehensive, or appropriately weighted than
the that of the problem domain experts.
But I think we both agree at root.
Cheers,
Euan
Gawnsoft: http://www.gawnsoft.co.sr
Symbian/Epoc wiki: http://html.dnsalias.net:1122
Smalltalk links (harvested from comp.lang.smalltalk) http://html.dnsalias.net/gawnsoft/smalltalk
| |
| Avner Ben 2004-03-18, 6:54 pm |
| Robert C. Martin wrote:
Not a completely accurate parallel. the constructor does not make the
object appear, neither does the destructor make it disappear. The object
allocation system does. the constructor is responsible for bringing the
object to a trustable state ("class invariant") before it can be used.
To be honest, the problem domain is unclear about this issue in the
first place. Buildings, for example, do not construct themselves (and
then, are they required to, in the first place? use the builder
pattern?). On the other hand, animals are responsible for some tasks
during their first moments of life. So the latter domain seems to call
for greater autonomy.
[color=darkred]
Obviously, good design must feature the best feasible compromise between
understanding the requirements and living with the limitations of the
clockwork presently available for implementing them. In my Opinion: (1)
The design process must start from the requirement side and (2) in OOD,
"understanding the requirements" positively means "modeling the domain".
[color=darkred]
>
> Schmuck: Sir, we need to buy a C++ compiler.
> etc.
The issue here is, really, should we see programming as a tool in the
service of management, or are we doomed to forever invent better
mousetraps, never stopping to ask why. for some obscure reason, the
poster insists on placing himself at the tatter camp.
Avner.
| |
| Avner Ben 2004-03-18, 6:54 pm |
| Robert C. Martin wrote:
>
> What is *real* modeling in a software context? It is the
> representation of some part of the problem or solution in a language
> that is simpler and cheaper to wield than code, for the purpose of
> testing an hypothesis, understanding a relationship, or communicating
> concepts with others. I use UML for this all the time.
Agreed!
The stress must be on "the right part". The bad name modeling has today
is due mainly to many people, out of good intention perhaps, modeling
the wrong domain. Two models of the same conceptual domain, but for
different purposes, are not necessarily similar and may even make
contradictory assumptions, using the same nouns and verbs. I take it
that what Martin says above is that modeling for itself is not enough -
concise, useful modeling is.
As to UML - I have my reservations.
>
> So, I think building models is very useful. I think *real* modeling
> is valuable. And I think there are far too many software "developers"
> who have gotten so carried away with building models that they have
> forgotten that their job is to produce working software.
>
Building models is useful mainly for these two purposes:
1. To demonstrate that we are indeed solving the right problem.
2. To allow evaluation of the cost of extension and modification of the
requirements, once the code is working.
It is the latter goal that is too often overlooked, with disastrous
results. Concise modeling gives resilience to change. Trying to assess
requirements for extension from code is as wise as trying to evaluate
the cost of adding a floor to a building by tapping on its walls.
Avner.
| |
| Lee Riemenschneider 2004-03-18, 6:54 pm |
| On Tue, 9 Mar 2004 05:43:34 UTC, Robert C. Martin
<unclebob@objectmentor.com> wrote:>
> I don't know who came up with "Objects should model the real world."
> but we need to find the guy and trash him soundly.
Real world problems need real world solutions. Certainly only a
schmuck would postulate that a circle isn't an ellipse. Not all
objects in the model will be physical real world entities, but the
object model as a whole will model something real. How can a problem
be perceived if it isn't real, and how could a solution to that
problem be unreal?
The original poster should look into translative model based
development where the real world realm is kept seperate from the
computing space realm.
--
Lee W. Riemenschneider
GO BOILERS!
Running eComStation (eCS)(the latest incarnation of OS/2)
Buy eCS everyone! Buy it now! http://www.ecomstation.com
| |
| Shayne Wissler 2004-03-18, 6:54 pm |
|
"Lee Riemenschneider" <newsuser@frogooa.com> wrote in message
news:cIWOGgi2d1Id-pn2-juGfJNChCYy2@frogooa...
> On Tue, 9 Mar 2004 05:43:34 UTC, Robert C. Martin
> <unclebob@objectmentor.com> wrote:>
>
> Real world problems need real world solutions.
True of course.
> Certainly only a
> schmuck would postulate that a circle isn't an ellipse.
Beside the point.
> Not all
> objects in the model will be physical real world entities, but the
> object model as a whole will model something real.
No, the program IS something real.
> How can a problem
> be perceived if it isn't real, and how could a solution to that
> problem be unreal?
A program is real.
Shayne Wissler
| |
| JXStern 2004-03-18, 6:54 pm |
| On Sat, 13 Mar 2004 01:48:53 -0600, "Lee Riemenschneider"
<newsuser@frogooa.com> wrote:
>
>Real world problems need real world solutions. Certainly only a
>schmuck would postulate that a circle isn't an ellipse. Not all
>objects in the model will be physical real world entities, but the
>object model as a whole will model something real. How can a problem
>be perceived if it isn't real, and how could a solution to that
>problem be unreal?
>
>The original poster should look into translative model based
>development where the real world realm is kept seperate from the
>computing space realm.
Pointers?
The term is new to me, though it seems the OMG stuff has been going on
for a couple of years now.
Google showed me this:
http://www.omg.org/mda/
http://www.omg.org/mda/presentations.htm
But, what does it *mean*? I gather that, at an operational level, it
means designing and implementing software by using modelling tools
instead of writing code. This has been the holy grail of software
development for, well, ever, and I see language about how maybe now
"its time has come."
I have nothing against it in principle, just a lot of questions about
just exactly what the claims are.
I'm also not quite certain what it implies to the OP's original
question, ... er, rant.
Regarding which, I never responded directly, but I believe I'm in
agreement with, as was RCM, and Shayne, too. I'm not entirely certain
what you were suggesting to the OP. I could agree with OP most
vehemently and at length, if there were any point in it.
As to perceiving things that aren't real, one can argue the
vocabulary, but certainly illusions and mistakes are common enough.
Joshua Stern
| |
|
|
| sirgilligan 2004-03-18, 6:54 pm |
| >
> I'm also not quite certain what it implies to the OP's original
> question, ... er, rant.
>
> Regarding which, I never responded directly, but I believe I'm in
> agreement with, as was RCM, and Shayne, too. I'm not entirely certain
> what you were suggesting to the OP. I could agree with OP most
> vehemently and at length, if there were any point in it.
>
> As to perceiving things that aren't real, one can argue the
> vocabulary, but certainly illusions and mistakes are common enough.
>
> Joshua Stern
Fellows,
My original "rant" (rant is accurate because it wasn't a question as
much as a statement) has to do with methods and behavior that are
needed only because we are "progamming". The issue started with a
class in which I was to validate several instances to be valid. One of
the validation criteria was to check equivalency. The class had no
method to do this. I asked the "author" of the class if he would
provide one (since it was his object and he had "domain" knowledge of
that object) and he said "No, the real world object doesn't have the
notion of equivalence and I do not want to break my model of the real
world." At that point I just stare slack jawed in disbelief. So, my
statement, "The real world object doesn't have a constructor, or a
destructor, but I see your object does!" (Me being a smartalic(sp?) to
make a point and start a fight). So, I have proposed two solutions.
One is the "2nd dimension of objects" and that it is OKAY to model the
behavior of the object in the real world and in the "computer" world.
The other argument (which I have not mentioned until now) was to not
adulterate the object and have a factory to create various objects and
to make a class I call a Judge (there is probably some accurately
named pattern for this) in which the Judge can be given two objects
and make declarations about those two objects such as equivalence or
similarity. Either approach works for me. I just want to ge the work
done and quit bickering and arguing over who modelled who!
Thanks for all of you posts. I am reading them all and learning alot.
Sincerely,
Geoff
| |
| Jeff Grigg 2004-03-18, 6:54 pm |
| sirgilligan@yahoo.com (sirgilligan) wrote...
> I think XP and other agile methods address the fact there the
> majority of programmers are not good at designing. [...]
It's true that should *all those other developers* get better at
designing, I'll have substantially less refactoring to do. ;->
*But*, that's not the whole story...
> My hope is that in agile development that the engineers will
> become tired of refactoring and tired of redesigning and try
> each iteration to do it right that time and that it will be
> the last refactoring for a given area.
When the business users get tired of coming up with new ideas for how
they can most effectively run their business, then this will happen.
In other words, it will never happen. Nor should it.
Even if we have *the perfect* design for the given requirements, the
business will change, or at least try to become more optimized. This
will create new requirements. The new requirements will make us add
complexity to the system. We will have to introduce new concepts into
the design, by refactoring, to manage the increasing complexity.
Our other choice is to throw each system away and build another
"perfect" system. But that's not very cost effective.
I've been doing refactoring for over 20 years. I find that when the
requirements stabilize, refactoring does come to a final stable point.
I've even seen that happen on *one* project (in my whole career).
But after a few months, they came up with some additional
requirements, which lead to additional code, which needed more
refactoring...
| |
| sirgilligan 2004-03-18, 6:54 pm |
| tsolakp@yahoo.com (Tsolak Petrosian) wrote in message news:<a052897d.0403090820.75bce9f0@posting.google.com>...
> Before adhering to real world you have to understand how real world
> works and its fundamental concepts (which is almost impossible for
> most developers, because they were not taught psychology and biology
> at school).
>
> Also why you think real world and OO are two different concepts?
>
> Tsolak Petrosian
I don't understand your question. Since it takes so many hours to push
a message through this system, I will make an attempt to interpret the
question. If I misinterpret your inquisition I appologize.
I am inclined to say that "everything is real world" but I know that
those schooled in thought and philosophy have a definition and in lay
terms is something like the "tactile world, or physical world, and
there are ideas or things that are pure thought that exist in
thought", and there may be other realms of existence that I have not
encountered. I haven't studied philosophy for many years and I am
rusty and not prepared to debate such things.
I will make an analogy, and ofcourse it can not be taken too far. A
wood carver that makes models of birds can carve a very accurate
representation of a bird. Usually the birds are carved sitting on a
small tree branch or some kind of roost. Why? Because of the medium I
suspect. A perched bird is only one of many dimensions of a bird and
its beauty. Many birds are most beautiful in flight. When a wood
carver makes a bird in flight, there is always a support of somekind.
Sometimes it is a rod that intersects the bird. Sometimes the wing tip
of the bird is attached to a carved tree trunk. No matter the
approach, the carving of the bird is attached to something to project
the idea of flight. Why. Because wood doesn't float in air. (Maybe the
carved birds should be suspended in glass or some other very viscuous
liquid. I am an artist and I think that would be beautiful!) The
carver accepts that the model will have to be implemented within the
constraints of the medium and the environment in which it exists. The
carver and the patron recognizes that the rod that holds the bird
model so that it represents flight is a necessary part of the model.
So, when we model a real world object or process in an OO fashion, we
should not exclude the fact that the model will be implemented in a
computer. Most computer languages are made of statements and there is
the basis of computer languages of sequence, selection, and iteration.
Also the concept of a finite state machine and the notion that you
need certain operations such as load and move.
Therefore, when we model an object we should accept the fact that the
medium has great influence on the model.
So, do I think real world is something different than OO? My
interpretation of your question makes me say, "No, I do not think so."
I am stretching the definition of real world to mean things that can
exist outside of the systems of a computer.
Sincerely
Geoff
| |
| Gawnsoft 2004-03-18, 6:54 pm |
| On 16 Mar 2004 05:26:56 -0800, jgrigg@mo.net (Jeff Grigg) wrote (more
or less):
>sirgilligan@yahoo.com (sirgilligan) wrote...
....
>
>When the business users get tired of coming up with new ideas for how
>they can most effectively run their business, then this will happen.
>In other words, it will never happen. Nor should it.
>
>Even if we have *the perfect* design for the given requirements, the
>business will change, or at least try to become more optimized. This
>will create new requirements.
Or the environment the business operates in will change.
Cheers,
Euan
Gawnsoft: http://www.gawnsoft.co.sr
Symbian/Epoc wiki: http://html.dnsalias.net:1122
Smalltalk links (harvested from comp.lang.smalltalk) http://html.dnsalias.net/gawnsoft/smalltalk
| |
| Tsolak Petrosian 2004-03-18, 6:54 pm |
| I'll repeat myself again: Whats important is fundamental concept.
In case of bird and its wood model, the fundamental concept was to
have physical
image of the bird.
Which is its body, wings and mouth and not its internal details such
as muscle or heart.
In case of modeling the bird into these virtual realm, our fundamental
concept will be:
Games:
Its geometrical capabilities (can be higher than ground elevation,
cannot pass through solid objects).
Electronic Music box:
Its specific sound waves.
Biology:
From heart structure to its sub molecular level.
As you see simulating real world is relative process and depends on
domain and its fundamental concepts.
Tsolak Petrosian
| |
| Universe 2004-03-18, 6:54 pm |
|
"Jeff Grigg" <jgrigg@mo.net> wrote in message
news:c794c0fd.0403160526.3c20bfb@posting.google.com...
> sirgilligan@yahoo.com (sirgilligan) wrote...
>
> It's true that should *all those other developers* get better at
> designing, I'll have substantially less refactoring to do. ;->
>
> *But*, that's not the whole story...
>
>
> When the business users get tired of coming up with new ideas for how
> they can most effectively run their business, then this will happen.
> In other words, it will never happen. Nor should it.
>
> Even if we have *the perfect* design for the given requirements, the
> business will change, or at least try to become more optimized. This
> will create new requirements. The new requirements will make us add
> complexity to the system. We will have to introduce new concepts into
> the design, by refactoring, to manage the increasing complexity.
Yet within a time period, many business contexts have no major changes. But
even
with changes, we should always try to have an at least minimally complete
overall
(holistic) analysis of all key aspects before implementing the bulk, or
logical high level
design heart of a software project.
Often after minimally complete analysis the verdict is "Don't Code". Or
a radically better and more elegant solution presents itself. XP'ers would
hardly ever see either of these options.
Elliott
--
The thing is that doing holistic investigation and creating
holistic plans at all times takes us as far ahead in terms of
understanding, as rapidly as possible while enabling us to
implement at all times in a way that supports what we
know will shortly be incorporated.
| |
| Ronald E Jeffries 2004-03-18, 6:54 pm |
| On Wed, 17 Mar 2004 11:36:55 -0500, "Universe"
<universe@tAkEcovadOuT.net> wrote:
>Yet within a time period, many business contexts have no major changes. But
>even
>with changes, we should always try to have an at least minimally complete
>overall
>(holistic) analysis of all key aspects before implementing the bulk, or
>logical high level
>design heart of a software project.
>
>Often after minimally complete analysis the verdict is "Don't Code". Or
>a radically better and more elegant solution presents itself. XP'ers would
>hardly ever see either of these options.
So it is apparently your view that
- the XP Release Plan, which causes the team to look at and estimate
all known stories;
- the presence of the customer with the team all the time;
- the team itself working together in a group and in pairs;
will somehow keep them from getting an overall view of the project?
I find that hard to understand. It almost seems that you're saying
things that just aren't true.
--
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.
| |
| JXStern 2004-03-18, 6:54 pm |
| On Thu, 18 Mar 2004 08:01:33 -0500, Ronald E Jeffries
<ronjeffries@acm.org> wrote:
>On Wed, 17 Mar 2004 11:36:55 -0500, "Universe"
><universe@tAkEcovadOuT.net> wrote:
>
>
>So it is apparently your view that
>
> - the XP Release Plan, which causes the team to look at and estimate
>all known stories;
> - the presence of the customer with the team all the time;
> - the team itself working together in a group and in pairs;
>
>will somehow keep them from getting an overall view of the project?
None of those seem the least bit relevant to what Universe is saying.
Though I do not know the XP dogma well enough to know if the XP
Release Plan is ever done before the first line of code is written -
is it? And to what end, having to do with release, would all known
stories be estimated - to assign implementation costs/times? Even
that is not really what the point of Uni's comments are.
>I find that hard to understand. It almost seems that you're saying
>things that just aren't true.
It seems to me you're aggressively misreading the subject and looking
for trouble.
--
What do I think of Uni's points? I don't buy holistic arguments, for
one thing. And I agree with him that the entire XP mindset is to
write code first, last, and always, whether it makes sense or not.
I'm not sure how often his scenario really occurs, that someone has an
idea for a system, does some significant analysis of the *concept*,
not the system itself, and slowly realizes it doesn't fly for some
pragmatic reason. Now and again, I guess. That entire discussion
would seem to take place out of the hearing of any XP'r, ever, as a
lot of the thought process involved is qualitative, domain-focused,
and non-computer-technical.
J.
| |
| Robert C. Martin 2004-03-18, 6:54 pm |
| On Thu, 18 Mar 2004 17:18:38 GMT, JXStern <JXSternChangeX2R@gte.net>
wrote:
---snip---
>I do not know the XP dogma well enough to know if the XP
>Release Plan is ever done before the first line of code is written
---snip---
>the entire XP mindset is to
>write code first, last, and always, whether it makes sense or not.
Can you reconcile these two statement for me? I can't quite see the
conclusion from the premise.
| |
| Universe 2004-03-18, 6:54 pm |
|
"Ronald E Jeffries" <ronjeffries@acm.org> wrote in message
news:b97j501lq2fjb3htd8quha49eidneqmshp@
4ax.com...
> On Wed, 17 Mar 2004 11:36:55 -0500, "Universe"
> <universe@tAkEcovadOuT.net> wrote:
>
But[color=darkred]
would[color=darkred]
>
> So it is apparently your view that
>
> - the XP Release Plan, which causes the team to look at and estimate
> all known stories;
> - the presence of the customer with the team all the time;
> - the team itself working together in a group and in pairs;
>
> will somehow keep them from getting an overall view of the project?
>
> I find that hard to understand. It almost seems that you're saying
> things that just aren't true.
Yet another classic example of what I mean by your "untoward" "twisting
and turning" regarding holding to principle.
Historically (the last ~3 years) most XP'ers and leading XP'er have
EXPLICITLY denied that:[color=darkred]
1) Read more carefully, 2) stop playing games, or 3) openly proclaim that
Jeffries XP "unstably" and with the principles of a jelly fish, stands
against
and for the same aspects of "Y", in the same context, simultaneously.
Elliott
--
http://www.univercenet.net
While Test Driven Design (TDD) tests are created from pre-coding
analysis, (minimally overall analysis?), if, as Dijkstra advises, at each
point system design is not *driven* (key design elements taken overall
in one direction or another) by core abstraction decomposition, the
interrelationships of core abstractions, tackling highest risks at the
outset, etc. there is a much greater chance of the averse as opposed
to the reverse occurring. !;- >
--
The thing is that doing holistic investigation and creating
holistic plans at all times takes us as far ahead in terms of
understanding, as rapidly as possible while enabling us to
implement at all times in a way that supports what we
know will shortly be incorporated.
| |
| Robert C. Martin 2004-03-18, 6:54 pm |
| On 18 Mar 2004 07:43:02 -0800, sirgilligan@yahoo.com (sirgilligan)
wrote:
>
>Ok. I think I understand. Thanks.
>
>I now think of a model of the human form. A sculpture like "David" may
>be of some significant person with an ideal in form. Another model of
>a person would be a manaquin in a store. It is to be a frame for
>clothing. Another model I think of is the anatomy "dummies" from
>school where you could open the chest and remove a model heart, a
>model lung, and such.
>
>David may be said to have modeled an ideal physique.
>The manaquin modeled the frame of a person.
>The anatomy dummie modeled external and internal systems of the human
>body.
Right. What's more, each model has a different purpose. Each model
is faithful to a human in one dimension while being vastly simplified
in many others. The aspect of the model that is accurate determines
the purpose of the model. It allows all other orthogonal concepts to
be disregarded.
Thus David is faithful to a human physique, but disregards the
physiology. The mannequin is faithful to the way clothing is used by
humans (the clothes can't tell the difference) but is not really
faithful to physique or physiology.
In this sense, model are simple probes of a complex domain. If the
model of some aspect of a complex domain withstands certain tests,
then it can be thought of as an accurate model, and can be used to
make decisions about the complex domain.
So it is with software. A model (and it does not have to be a UML
model) is faithful in one dimension while treating other dimensions as
irrelevant to the purpose of the model. A module diagram does not
show the function of the system, but is faithful to the way the
modules depend on each other. A class diagram does not expose the
algorithm, but does show the interrelationships between the classes.
A domain model expresses the concepts in the problem domain without
concerning itself with software structure. etc. etc.
The problem we have at the moment is that some folks have decided that
a model is a *specification*, that it is faithful in *all* respects
except low level detail. They expect that a model of the domain is
strongly indicative of the software structure; or that a model of the
relationships between real world entities maps reliably onto the
structure of the software. Such thinking is not using models as
simple probes of a complex domain. Rather it elevates the notion of a
model to the level of a specification. The model becomes the "truth",
and reality becomes the probe. There have been cases where I have
seen reality challenged because it doesn't match the model.
The circle/ellipse problem is just one small example of this
inversion. Since a circle ISA ellipse in geometry, some folks demand
that a circle class must inherit from an ellipse class in software.
This flies in the face of the reality that a circle requires only two
variables to describe it while an ellipse requires three. But for
some folks the reality is less important than the model.
Eric Evan's new book "Domain Driven Design" tries to keep this balance
pretty well. While he is a strong advocate of building models of the
problem domain, he is also determined to keep the models tied to the
realities of the code.
| |
| Ronald E Jeffries 2004-03-19, 1:17 pm |
| On Thu, 18 Mar 2004 13:13:34 -0500, "Universe"
<universe@tAkEcovadOuT.net> wrote:
>Historically (the last ~3 years) most XP'ers and leading XP'er have
>EXPLICITLY denied that:
>
>1) Read more carefully, 2) stop playing games, or 3) openly proclaim that
>Jeffries XP "unstably" and with the principles of a jelly fish, stands
>against
>and for the same aspects of "Y", in the same context, simultaneously.
Historically I have called you on this many many times, pointing out
every time that the release plan process, which is mentioned in the
very first XP book (and in mine, and in the book Planning Extreme
Programming, ...) is precisely a consideration of all key use cases.
--
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.
| |
| Universe 2004-03-19, 1:17 pm |
|
"Ronald E Jeffries" <ronjeffries@acm.org> wrote in message
news:6dnk50h2i32afvcc2j86cklr6i14g940np@
4ax.com...
> On Thu, 18 Mar 2004 13:13:34 -0500, "Universe"
> <universe@tAkEcovadOuT.net> wrote:
>
or[color=darkred]
>
> Historically I have called you on this many many times, pointing out
> every time that the release plan process, which is mentioned in the
> very first XP book (and in mine, and in the book Planning Extreme
> Programming, ...) is precisely a consideration of all key use cases.
I stand by point as overriding and reflecting the main truth about XP. XP
is
more than Ronald Jeffries.
And **EVERY** other XP'er whose book, paper, column, Letter to the Editor,
and post to Usenet, I have read states what I state above.
Elliott
| |
| Jason Nocks 2004-03-19, 1:17 pm |
| Universe wrote:
> "Jeff Grigg" <jgrigg@mo.net> wrote in message
> news:c794c0fd.0403160526.3c20bfb@posting.google.com...
>
>
>
> Yet within a time period, many business contexts have no major changes. But
> even
> with changes, we should always try to have an at least minimally complete
> overall
> (holistic) analysis of all key aspects before implementing the bulk, or
> logical high level
> design heart of a software project.
The reason we create software instead of hardware is because it is
supposed to be easy to change. If you don't think that your software
should have to change, maybe you should go into the world of hardware
design, or perhaps firmware (but even that changes).
To me, XP is about trying to get back to making software easy to change
again.
Big upfront analysis and design often achieves quite the opposite.
In XP, we try to continually improve the design to accomodate each new
requirement.
>
> Often after minimally complete analysis the verdict is "Don't Code". Or
> a radically better and more elegant solution presents itself. XP'ers would
> hardly ever see either of these options.
Minimally complete analysis sounds like an oxymoron. Which is it?
Minimal or complete? And, how do you even know when you are done with
analysis? Couldn't you always do more analysis, just to make sure you
haven't missed something?
And you admit that after your "complete analysis" that a more elegant
solution presented itself. So, now you have to redo the majority of your
analysis and/or design. Wasn't much of the first series of analysis
and/or design wasted effort then? If your holistic analysis approach is
so much superior, why didn't you start with the more elegant (probably
simpler) solution the first time?
In XP, the intent is to get to the simplest (more elegant) approach as
quickly as possible. IMHO, this requires getting feedback about what the
implementation details might look like as soon as possible.
After all, "The software is the design" - I forget who came up with that
quote.
So, it seems that your hypothetical project gets cancelled because you
wasted the budget doing analysis. Your conclusion is that the problem
was not solvable within the budget constraints. With your approach, that
seems to be the only logical conclusion.
In the meantime, an XP group would have already delivered several
working iterations that the customer can use to make an informed
decision as to whether or not what is being delivered is worth the cost
and how long it will take to get to some definition of complete. The
customer gets the opportunity to decide whether or not the project is
worth the cost, not some perceived complete holistic approach that turns
out to require too much effort.
As a consultant, I am well compensated for every hour of effort I put
forth. Wasted effort results in wasted dollars for my customers. My
response to Big Upfront Analysis and Design is no thanks, I value my
customers too much.
I am able to give them as much information about where we are headed
with the design as often as they wish, but I give them no more than
that. Because the customer is footing the bill.
In XP, if there are questions about what approach to take, a spike
should be undertaken to find out quickly (most likely days or hours).
So, if the result is that an approach will not work, it should be found
in very short order.
>
> Elliott
> --
> The thing is that doing holistic investigation and creating
> holistic plans at all times takes us as far ahead in terms of
> understanding, as rapidly as possible while enabling us to
> implement at all times in a way that supports what we
> know will shortly be incorporated.
>
>
Analysis is often anthing but rapid and will not result in
implementation if the bulk of the budget evaporates doing analysis and
design. What is the customer paying for, analysis and design, or working
software? In my case, it's ususally working software that they are after.
Cheers,
Jason Nocks
SourceXtreme, Inc.
http://www.sourcextreme.com/
| |
| Jason Nocks 2004-03-19, 1:17 pm |
| JXStern wrote:
> On Thu, 18 Mar 2004 08:01:33 -0500, Ronald E Jeffries
> <ronjeffries@acm.org> wrote:
>
> None of those seem the least bit relevant to what Universe is saying.
> Though I do not know the XP dogma well enough to know if the XP
> Release Plan is ever done before the first line of code is written -
> is it? And to what end, having to do with release, would all known
> stories be estimated - to assign implementation costs/times? Even
> that is not really what the point of Uni's comments are.
Here is one of the definitions I get from a quick check of dict.org:
dogma - n 1: a religious doctrine that is proclaimed as true without
proof [syn: tenet] 2: a doctrine or code of beliefs accepted as
authoritative; "he believed all the Marxist dogma"
First of all, IMHO most of the XP community freely admits that XP is not
for everyone. I'm sure I've heard this from Uncle Bob. I'm sure I've
heard it from others. I mainly hear "this works for me". If you want to
try it, great. If not, just don't state a falsehood as the reason you
don't think it's for you.
Also, XP highly values feedback. This is the opposite of blindly follow
along and you will reach some state of enlightenment.
<snip>
>
> What do I think of Uni's points? I don't buy holistic arguments, for
> one thing. And I agree with him that the entire XP mindset is to
> write code first, last, and always, whether it makes sense or not.
>
This seems to be a common misconception generally held by people who are
unfamiliar with XP. IMHO, reality is quite the opposite. In fact, it's
quite literally write TESTS first (and almost always). It's also
continually think about the design. Not just write some code.
The idea is to find out whether the interfaces of my objects will make
sense sooner rather than later. If some set of classes would best be
designed by gathering around a white board and drawing up some ideas,
then according to what I've read from XP, that's probably what you
should do. But only for that set of classes. If the best way to work out
a design for some other functionality is with CRC cards, then do that.
The idea is to do what makes sense, exactly not blindly following some
doctrine.
> I'm not sure how often his scenario really occurs, that someone has an
> idea for a system, does some significant analysis of the *concept*,
> not the system itself, and slowly realizes it doesn't fly for some
> pragmatic reason. Now and again, I guess. That entire discussion
> would seem to take place out of the hearing of any XP'r, ever, as a
> lot of the thought process involved is qualitative, domain-focused,
> and non-computer-technical.
Not sure why you think that conceptual discussions or analysis would be
out of the hearing of an XP team. The XP team is constantly s ing the
feedback of the customer about the concepts that the customer thinks
that he or she wants. In fact, the customer is part of the team. I think
that was one of the points that Ron Jeffries was driving at.
And, why should the analysis of the concept of the system be different
than analysis of the system itself? If by concept you mean model, that
would seem to indicate that the model is not adequately representing the
system.
Which is more important? The actual system, or some model which does not
even represent the actual system? And, why? Which is the customer trying
to purchase or acquire? Which would the customer rather have? Working,
tested code, or a conceptual model? For me, my customers seem to want
working tested code. If I only deliver documentation, my customers
aren't very happy. Sure, they often ask for both, but the actual working
system is generally more important. So, I try to make sure that I can at
least deliver that.
And you indicate that the thought process "is qualitative,
domain-focused, and non-computer-technical". I think that these
statements are off the mark at best. Is the customer going to have an
easier time reading through design diagrams or working with an early
version of the system?
>
> J.
>
For the record, I am just trying to help clear up what to me are
misconceptions about XP.
Cheers,
Jason Nocks
SourceXtreme, Inc.
http://www.sourcextreme.com/
| |
| Jason Nocks 2004-03-19, 1:17 pm |
| Jason Nocks wrote:
>JXStern wrote:
> This seems to be a common misconception generally held by people who are
> unfamiliar with XP. IMHO, reality is quite the opposite. In fact, it's
> quite literally write TESTS first (and almost always). It's also
I've been so focused on explaining TDD to other people lately that
somehow I didn't think to mention the Planning Game, Acceptance Tests, etc.
Without a User Story, nothing happens. Without an acceptance test,
generally no code should be written. So, the point remains the same.
Yes, there is emphasis on working, well-designed code. But, there are
about 12 major XP practices that strive to make that goal more
achievable, and a significant number of less promoted, but still
important supporting practices.
I'm not a big wiki guy yet, so it took me a bit to find, but here's the
current list of documented (see, XP practioners really do write some
documentation) XP practices:
http://www.c2.com/cgi/wiki?ExtremeP...ngCorePractices
>...
Cheers,
Jason Nocks
SourceXtreme, Inc.
http://www.sourcextreme.com/
| |
| Ronald E Jeffries 2004-03-19, 1:17 pm |
| Xref: kermit comp.software.extreme-programming:27766 comp.object:114888
On Thu, 18 Mar 2004 21:58:58 -0500, "Universe"
<universe@tAkEcovadOuT.net> wrote:
>
>I stand by point as overriding and reflecting the main truth about XP. XP
>is
>more than Ronald Jeffries.
>
>And **EVERY** other XP'er whose book, paper, column, Letter to the Editor,
>and post to Usenet, I have read states what I state above.
Well, there are these books:
Beck, Extreme Programming Explained: Planning Strategy, pp 85ff
Jeffries et al., Extreme Programming Installed: Customer Defines
Release, pp 55ff.
Auer & Miller, Extreme Programming Applied, The Planning Game, pp
122ff.
Beck & Fowler, Planning Extreme Programming: Release Planning, pp
39ff.
Wake, Extreme Programming Explored: How Do You Plan A Release?, pp
99ff.
Astels et al., A Practical Guide to eXtreme Programming: Planning
Releases, pp 75ff.
These web pages:
http://c2.com/cgi/wiki?ReleasePlan
http://www.xprogramming.com/xpmag/whatisxp.htm#planning
http://www.extremeprogramming.org/rules/commit.html
http://www.xp123.com/xplor/xp0002g/index.shtml
http://www.industriallogic.com/cata...ies/000010.html
http://www.mayford.ca/xp/release_plan.shtml
I don't know what you've been reading. Could you find, perhaps, one
quote somewhere that says we don't consider all the stories we have?
Or are you suggesting, somehow, that we are bad because we don't
consider information which we DON'T have?
Now, it is absolutely true that we do not use the phrase "holistically
consider all key use cases". As far as I can determine, that phrase is
unique to you, and happily so. The key point is that the XP practices
and circumstances all come together to cause the whole team to
consider all the stories that they have, whether all the requirements
are known or not.
Some processes insist on all the requirements being stated up front.
This is, of course, fatuous.
After years of saying "all", some correspondents have started saying
"all key". That's fine and good, except that there is no way to know
whether you have them, and in any case they might change.
XP allows you to start with whatever you have. It makes no particular
recommendations about having "all key", I suspect for at least two
reasons:
1. Pretty much no one starts a project without knowing all the
important things they want in it;
2. Incremental and iterative development work on a minimal up-front
commitment to architecture, evolving the design as things are added.
This allows for a long period where the system is not committed overly
in one direction, so that even if -- and I emphasize if -- some new
requirement comes along, we find that we can typically handle it quite
nicely.
It's time for a new rap against XP. This holistic all key use cases
one just doesn't hold together. Or maybe -- this would be really 
-- you could dig into it and learn the subject and actually contribute
something other than ill-founded claims and concerns. I'd love that.
You're smart, you could contribute if you really wanted to.
Regards,
--
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.
| |
| Universe 2004-03-19, 1:17 pm |
| "Jason Nocks" <nocksj@sourcextreme.com> wrote in message
news:9c74b$405aa659$cff54506$7037@dcanet
.allthenewsgroups.com...
> Universe wrote:
>
But[color=darkred]
complete[color=darkred]
>
> The reason we create software instead of hardware is because it is
> supposed to be easy to change. If you don't think that your software
> should have to change, maybe you should go into the world of hardware
> design, or perhaps firmware (but even that changes).
>
> To me, XP is about trying to get back to making software easy to change
> again.
Cybernetics, I readily concur, shines in ease with which it handles for
instance business transaction use case daily sales. But that is a different
kind of change from major changes in how those transactions are handled
and whether or not specific transaction "A" will even continue to exist
for the organization.
> Big upfront analysis and design often achieves quite the opposite.
>
> In XP, we try to continually improve the design to accommodate each new
> requirement.
Rapid change in the latter are the kind that impact changes in the
use case reqs for a cybernetic project.
would[color=darkred]
[color=darkred]
> Minimally complete analysis sounds like an oxymoron.
Essence is not necessarily identical with "moronic" Appearance. :- >
> Which is it? Minimal or complete?
Dialectically both.
Please demonstrate their incompatibility as an opposition. Please
demonstrate how the 2 opposites do form dialectic that can be managed
and leveraged to our benefit in contexts where as I've said in the past:
"doing holistic investigation and creating
holistic plans at all times takes us as far ahead in terms of
understanding, as rapidly as possible while enabling us to
implement at all times in a way that supports what we
know will shortly be incorporated."
> And, how do you even know when you are done with
> analysis? Couldn't you always do more analysis, just to make sure you
> haven't missed something?
Convergence - Slowed velocity in changes in understanding the domain
and use cases - Domain experts on the Analysis team are happy - Etc.
More on the remainder of your post later,
Elliott
--
http://www.univercenet.net
I prefer designing to spec via project relevant collaborating domain
entity
responsibility, and expressed as collaborating objects in the high level
project solution model.
Before code goes into production it must be rigorously tested to spec.
All in all rather than I drive design by tests, I advise generally
driving design by
object models that at least cover all key design elements overall.
| |
| Universe 2004-03-19, 1:17 pm |
| "Jason Nocks" <nocksj@sourcextreme.com> wrote:
> Jason Nocks wrote:
[color=darkred]
TESTS, as part, an aspect of the overall - "gasp", XP'ers please avert
eyes -
*whole* process of coding.
[color=darkred]
> I've been so focused on explaining TDD to other people lately that
> somehow I didn't think to mention the Planning Game, Acceptance Tests,
etc.
>
> Without a User Story, nothing happens. Without an acceptance test,
> generally no code should be written. So, the point remains the same.
> Yes, there is emphasis on working, well-designed code. But, there are
> about 12 major XP practices that strive to make that goal more
> achievable, and a significant number of less promoted, but still
> important supporting practices.
You're right, XP often literally doesn't code 1st but in effect they do.
By that I mean XP by practices the *essence* of hackery, which is
piecemeal one "User Story" at a time coding and deployment.
The proper scientifico-engineering methodology approach is where
at least minimal overall study and design for at least all key use cases
is done before the bulk of the heart of high level coding is done.
This is the essence of the genuine RUP, holistic, model driven design
approach.
Elliott
--
http://www.univercenet.net
XP TDD tests are created from some degree of pre-coding analysis.
(Though XP does not mandate doing minimally *overall* analysis of
the use case currently being coded, much less minimally *overall*
investigation of at least all key project use cases, singly then as a
group [project scope]). However, Dijkstra recommends that system
design be *driven* (driven: key design elements overall are "steered"
in one direction or another) by core abstraction decomposition, the
interrelationships of core abstractions, tackling highest risks at the
outset, etc. Given that Dijkstra's approach here is not central to
XP/Alliance TDD, there is a much greater chance of the averse as
opposed to the reverse occurring. !;- >
| |
| Universe 2004-03-19, 1:17 pm |
| [TyPo]
"Universe" <universe@tAkEcovadOuT.net> wrote:
> ...
> Please demonstrate their incompatibility as an opposition. Please
> demonstrate how the 2 opposites do form [a] dialectic that can be managed
> and leveraged to our benefit in contexts where as I've said in the past:
> ...
Rather:
> ...
> Please demonstrate their incompatibility as an opposition. Please
> demonstrate how the 2 opposites
*** (minimal & complete) do _not_ ***
> form a dialectic that can be managed
> and leveraged to our benefit in contexts where as I've said in the past:
> "doing holistic investigation and creating
> holistic plans at all times takes us as far ahead in terms of
> understanding, as rapidly as possible while enabling us to
> implement at all times in a way that supports what we
> know will shortly be incorporated."
Elliott
| |
| Jason Nocks 2004-03-19, 1:17 pm |
| Universe wrote:
> "Jason Nocks" <nocksj@sourcextreme.com> wrote in message
> news:9c74b$405aa659$cff54506$7037@dcanet
.allthenewsgroups.com...
>
<snip>
[color=darkred]
>
> would
>
>
>
> Essence is not necessarily identical with "moronic" Appearance. :- >
>
>
> Dialectically both.
>
> Please demonstrate their incompatibility as an opposition. Please
<snip>
I said "sounds like".
Anyway, From dict.org:
complete: Filled up; with no part or element lacking; free from
deficiency; entire; perfect; consummate.
minimal: Of, pertaining to, or having a character of, a minim or
minimum; least; smallest; as, a minimal amount or value.
I'm not saying they *can't* be used together, I'm just saying it's odd,
that's all. Minimal analysis versus complete analysis imply very
different things to me. I'm not even sure what they mean independently.
The combination is very unclear. Sufficiently defining what done means
would probably clear it up. But we discuss that below.
>
>
> Convergence - Slowed velocity in changes in understanding the domain
> and use cases - Domain experts on the Analysis team are happy - Etc.
When I say, "how do you even know when you are done", I am looking for
something that results in a boolean yes/no response. "Slowed velocity in
changes" is not the same as "complete". What is the definitive end
point? Something contractually definable. Something clear, concise, and
unambiguous. IMHO, this endpoint does not exist (or is arbitrary).
>
> More on the remainder of your post later,
>
> Elliott
> --
<snip>
Cheers,
Jason Nocks
SourceXtreme, Inc.
http://www.sourcextreme.com/
| |
| Universe 2004-03-19, 1:17 pm |
| "Ronald E Jeffries" <ronjeffries@acm.org> wrote in message
<< "Universe" <universe@tAkEcovadOuT.net> wrote:
<<<
Historically (the last ~3 years) most XP'ers and leading XP'er have
EXPLICITLY denied that:
we should always try to have an at least minimally complete overall
(holistic) analysis of all key aspects before implementing the bulk,
or logical high level design heart of a software project.[color=darkred]
Convenient how with lack of intellectual integrity, you DELETED MY
ESSENTIAL POINT.
Don't want them to compare readings in the listing below with
my statement? Likely, they'll see I'm correct, innit?
For the record, I re-quoted above the widely accepted - both without
and *within* the XP camp - point that Jeffries ludicrously denies:
As I said to Jeffries on denying my main point:[color=darkred]
that[color=darkred]
against[color=darkred]
Jeffries:[color=darkred]
Elliott:[color=darkred]
XP[color=darkred]
Editor,[color=darkred]
EVERYONE except you NOW Jeffries knows this about XP:
<<<
Historically (the last ~3 years) most XP'ers and leading XP'er have
EXPLICITLY denied that:
we should always try to have an at least minimally complete overall
(holistic) analysis of all key aspects before implementing the bulk,
or logical high level design heart of a software project.[color=darkred]
Elliott
--
The thing is that doing holistic investigation and creating
holistic plans at all times takes us as far ahead in terms of
understanding, as rapidly as possible while enabling us to
implement at all times in a way that supports what we
know will shortly be incorporated.
| |
| Universe 2004-03-19, 1:17 pm |
| "Jason Nocks" <nocksj@sourcextreme.com> wrote in message
news:667ae$405af508$cff54506
> Elliott wrote:
news:667ae$405af508$cff54506[color=darkr
ed]
[color=darkred]
[color=darkred]
> When I say, "how do you even know when you are done", I am looking for
> something that results in a boolean yes/no response. "Slowed velocity in
> changes" is not the same as "complete". What is the definitive end
> point? Something contractually definable. Something clear, concise, and
> unambiguous. IMHO, this endpoint does not exist (or is arbitrary).
1st Analysis is never "sewn up, jelly tight" *complete*.
2nd Why are up so stressed about "complete" Analysis?
I defined how genuine holistic, MDA RUP handles our Analysis within our
IID - iterative & incremental development.
Holistic, MDA'ers know that due to project feedback, changes in the
domain, changes in use case reqs that both Analysis and Design may
be modified, and even tossed.
Someone told you RUPists requires "Boolean complete* analysis before
the heart of high level production code and you want me to concur
with that mythological fantasy, that lie, that XP "straw man".
Elliott
--
The thing is that doing holistic investigation and creating
holistic plans at all times takes us as far ahead in terms of
understanding, as rapidly as possible while enabling us to
implement at all times in a way that supports what we
know will shortly be incorporated.
--
http://www.univercenet.net
I prefer designing to spec via project relevant collaborating domain
entity
responsibility, and expressed as collaborating objects in the high level
project solution model.
Before code goes into production it must be rigorously tested to spec.
All in all rather than I drive design by tests, I advise generally
driving design by
object models that at least cover all key design elements overall.
| |
| Jason Nocks 2004-03-19, 1:17 pm |
| Universe wrote:
> "Jason Nocks" <nocksj@sourcextreme.com> wrote:
>
>
>
>
>
>
>
>
> TESTS, as part, an aspect of the overall - "gasp", XP'ers please avert
> eyes -
> *whole* process of coding.
>
First of all, tests are not what I consider to be shipping code. When I
refer to coding, I'm usually referring to the fundamental act of
creating the software that the customer desires. The tests, only some of
which are actually represented in actual code (see http://fitnesse.org/
for examples of tests comprised of tables filled in by the customer) are
a means to this end, but not the end itself.
Second, you completely ignore the part about Planning, Stories, Design,
etc. Planning is not coding, defining stories is not coding, coming up
with a simple design is not coding, ...
>
>
> etc.
>
>
>
> You're right, XP often literally doesn't code 1st but in effect they do.
Now you are completely contradicting yourself and making no sense to me
whatsoever.
>
> By that I mean XP by practices the *essence* of hackery, which is
> piecemeal one "User Story" at a time coding and deployment.
I have absolutely no idea where you came up with "one 'User Story' at a
time". On every XP-style project that I've ever seen or heard of an
iteration consisted of a number of stories. And these were planned,
designed, tested, and yes coded as part of that iteration. For some
strange unknown reason, you conveniently leave out the planning,
designing, and testing.
Deployment may not even happen until several iterations have been
completed. This depends on the size and scope of the project, and is
frequently called a Release. The first real release probably rarely ever
happens at the first iteration (probably a minimum of 2-3 iterations).
Testing is often called Quality Assurance. Wouldn't you like to work on
a project where thourough QA is guaranteed, because it's done before
coding? I rarely see non-XP style projects perform extensive QA.
>
> The proper scientifico-engineering methodology approach is where
Actually, engineering is generally recognized as applied science.
Engineering involves tradeoffs between scientific ideals and real-world
efficiencies. And even in science, controlled experiments are undertaken
early to gather feedback before hypothesizing for too long. Scientists
generally will not write up their entire research thesis before trying a
single experiment to see if they are on track at all. Most would
probably try a quick experiment before pondering a point too long to
determine if a research project is even worth their while. Imagine
trying to get research money on pure speculation alone.
Your "holistic minimal complete analysis" is equivalent to running a
research project that involves creating a simulated environment followed
by numerous simulated trials with the simulated environment before ever
running a single real-world experiment.
I'm sure there are a few areas of science where the laws of physics
might steer in that direction, however the more readily available the
real-world test, the more obvious it is that an actual scientific study
would try out a quick real-world test before spending too much research
money on what is potentially wasted effort.
Thanks for the great analogy.
> at least minimal overall study and design for at least all key use cases
> is done before the bulk of the heart of high level coding is done.
Again, please stop insisting that XP developers don't design and simply
sit down and throw together code when I have already explained why that
is simply not the case.
<snip>
> Elliott
Cheers,
Jason Nocks
SourceXtreme, Inc.
http://www.sourcextreme.com/
| |
| sirgilligan 2004-03-19, 1:17 pm |
| Robert C. Martin <unclebob@objectmentor.com> wrote in message news:<nmpj5093dieuunn9k5ct5of7oeti53f9lu@4ax.com>...
> On 18 Mar 2004 07:43:02 -0800, sirgilligan@yahoo.com (sirgilligan)
> wrote:
>
> and reality becomes the probe. There have been cases where I have
> seen reality challenged because it doesn't match the model.
>
Yep. Tail wagging the dog may be a valid analogy.
Thanks.
Geoff
| |
| Jason Nocks 2004-03-19, 1:17 pm |
| Universe wrote:
> By that I mean XP by practices the *essence* of hackery, which is
> piecemeal one "User Story" at a time coding and deployment.
I responded to what I felt were misunderstandings of XP in my other post(s).
As an aside, if you are using hackery in a perjorative sense, please
don't. The word hacker has a long-standing tradition of being a positive
word in the realm of software development.
From the hack.gr version (http://www.hack.gr/jargon/) of the on-line
hacker Jargon File, version 4.1.0:
hacker n.
[originally, someone who makes furniture with an axe] 1. A person who
enjoys exploring the details of programmable systems and how to stretch
their capabilities, as opposed to most users, who prefer to learn only
the minimum necessary. 2. One who programs enthusiastically (even
obsessively) or who enjoys programming rather than just theorizing about
programming. 3. A person capable of appreciating hack value. 4. A person
who is good at programming quickly. 5. An expert at a particular
program, or one who frequently does work using it or on it; as in `a
Unix hacker'. (Definitions 1 through 5 are correlated, and people who
fit them congregate.) 6. An expert or enthusiast of any kind. One might
be an astronomy hacker, for example. 7. One who enjoys the intellectual
challenge of creatively overcoming or circumventing limitations. 8.
[deprecated] A malicious meddler who tries to discover sensitive
information by poking around. Hence `password hacker', `network hacker'.
The correct term for this sense is cracker.
....
This term seems to have been first adopted as a badge in the 1960s by
the hacker culture surrounding TMRC and the MIT AI Lab. We have a report
that it was used in a sense close to this entry's by teenage radio hams
and electronics tinkerers in the mid-1950s.
If you meant this definition of the word hacker, than I apologize and I
am flattered, although I'm not sure that I am deserving of the title.
> Elliott
Cheers,
Jason Nocks
SourceXtreme, Inc.
http://www.sourcextreme.com/
| |
| JXStern 2004-03-19, 1:17 pm |
| On Fri, 19 Mar 2004 08:07:45 -0500, "Universe"
<universe@tAkEcovadOuT.net> wrote:
>TESTS, as part, an aspect of the overall - "gasp", XP'ers please avert
>eyes -
>*whole* process of coding.
Jason,
What Uni says. Everything you've said is about coding. This is all
XP is about, and all that it contributes to the art and science of
methodology. Now, before any XP'r denies this, you have to understand
that IT IS A GOOD THING. It is a fascinating and potentially crucial
idea that coding first, last, and always might be the key to software
development. The idea needs to be evaluated, studied, and understood.
Yeah, even from the beginning XP had some other stuff, but (outside of
pair programming) nothing that others haven't said and done for
decades. And, 99% of it conflicts with the basic idea of code, code,
code, so frankly I can't even take it seriously as anything but
defensive constructions around the major idea.
I only speechify here because the thread is cross-posted into the XP
newsgroup, which I have generally avoided since playing around there
several years ago and never having a discussion there I found
reasonable.
Finally, this whole rant is almost on-topic to the original thread,
which had a guy working in an environment in which his management
imagined code to have magic properties of similarity with real-world
objects. A common-enougn misconception. XP doesn't really commit one
to or against this, that I can see, but it seems to present related
questions.
J.
| |
| JXStern 2004-03-19, 1:17 pm |
| On Thu, 18 Mar 2004 12:02:30 -0600, Robert C. Martin
<unclebob@objectmentor.com> wrote:
>---snip---
>
>Can you reconcile these two statement for me? I can't quite see the
>conclusion from the premise.
You snipped my guess at what and where the release plan is, and did
not correct it. Anyway, the conclusion is known to be true, no matter
what you think is a premise here.
To be more specific, if a customer wants code written, I have never
seen any XP advice to recommend against it, no matter how silly it may
seem to the developer.
J.
| |
| Tsolak Petrosian 2004-03-19, 8:40 pm |
| Well put.
| |
|
| JXStern wrote:
> On Fri, 19 Mar 2004 08:07:45 -0500, "Universe"
> <universe@tAkEcovadOuT.net> wrote:
[color=darkred]
> Jason,
> What Uni says. Everything you've said is about coding. This is all
"Everything you've said is about coding." - this is a completely false
statement. I have talked very much about activities and practices that are
NOT CODING in the last few posts.
> XP is about, and all that it contributes to the art and science of
> methodology. Now, before any XP'r denies this, you have to understand
It's not a matter of denying anything. I am supplying you with facts.
These facts indicate that your statement is incorrect. And you appear to
have completely ignored what I have said in this thread more than once
(not sure that I blame you - it's probably uninteresting to most if not
all by now). I will repost a snippet here to try to make it easy for you.
"Second, you completely ignore the part about Planning, Stories, Design,
etc. Planning is not coding, defining stories is not coding, coming up
with a simple design is not coding, ..." - me
What don't you understand? The activities listed above are simply NOT
CODING! And yet, these activities are core XP practices. So, if all an XP
team does is code, what do these practices mean to you?
> that IT IS A GOOD THING. It is a fascinating and potentially crucial
I'm glad you're pleased with the coding aspects in XP, but you are missing
out on plenty of other activities and practices that go on ALL THE TIME,
which I have listed above for about the third or fourth time.
> idea that coding first, last, and always might be the key to software
> development. The idea needs to be evaluated, studied, and understood.
Fine, but you are simply not talking about XP at this point. End of story.
> Yeah, even from the beginning XP had some other stuff, but (outside of
> pair programming) nothing that others haven't said and done for
> decades. And, 99% of it conflicts with the basic idea of code, code,
> code, so frankly I can't even take it seriously as anything but
Here, you completely contradict yourself. First, you say that XP is only
about coding. Then you indicate that 99% of what you see conflicts with
your notion of "code, code, code". How can you expect me to take your
argument seriously?
Well, I for one had never heard of onsite customer, CRC cards, or much of
the planning game (particularly velocity) before XP. None of these are
coding activities.
> defensive constructions around the major idea.
> I only speechify here because the thread is cross-posted into the XP
> newsgroup, which I have generally avoided since playing around there
> several years ago and never having a discussion there I found
> reasonable.
I'm trying to be reasonable here. Unfortunately, I feel as though I am not
seeing a sensible response. Defining XP as something other than what it
is, presenting this to the very people who are practicing it, and not
listening to the response is probably a good recipe for a poor reception.
Is this a surprise?
> Finally, this whole rant is almost on-topic to the original thread,
> which had a guy working in an environment in which his management
> imagined code to have magic properties of similarity with real-world
> objects. A common-enougn misconception. XP doesn't really commit one
> to or against this, that I can see, but it seems to present related
> questions.
Now you are starting to get back to a more interesting topic.
Unfortunately, I suspect most have long lost interest in this thread
(myself mostly included).
I have merely been trying to address what I perceive as misconceptions
about XP. I intend no ill will or unreasonable attitude.
> J.
Cheers,
Jason Nocks
SourceXtreme, Inc.
http://www.sourcextreme.com/
| |
| Robert C. Martin 2004-03-26, 11:50 pm |
| On Fri, 19 Mar 2004 16:47:31 GMT, JXStern <JXSternChangeX2R@gte.net>
wrote:
>On Thu, 18 Mar 2004 12:02:30 -0600, Robert C. Martin
><unclebob@objectmentor.com> wrote:
>
>
>You snipped my guess at what and where the release plan is, and did
>not correct it.
No need to guess. The Release Plan practice is well known and well
documented in the XP materials. Once stories have been gathered and
estimated, the stakeholders and developers meet to plan the next
release. The release is typically 3 months worth of development
effort. The stakeholders will choose those stories that provide the
most business value, and whose estimates are compatible with the
release time frame.
From those stories the stakeholders will then choose stories for the
next iteration. Once the iteration stories are chosen, development of
those stories can begin.
So, in fact, the release plan is in place before any significant
development work is begun.
>Anyway, the conclusion is known to be true, no matter
>what you think is a premise here.
I can't disagree with your statement since /you/ clearly know it to be
true. I simply don't agree with your "knowledge". XP is, first and
foremost, about doing the things that make the most sense at the most
opportune times.
>To be more specific, if a customer wants code written, I have never
>seen any XP advice to recommend against it, no matter how silly it may
>seem to the developer.
I don't believe that you have looked very closely at the XP materials.
XP makes a big deal out of separating customer responsibilities and
rights, fro mm developer responsibilities and rights. The customer
has the right to tell the developers what features they want, and in
what order they want them. The customer has no right at all to tell
the developers what /code/ to write. The developers have the right to
tell the customer what the features will cost to develop. The
developers also have the right to produce the best code they can, and
to use whatever tools or techniques that professionalism dictates.
It's long past time to get over the fear that XP is a hack and slash
technique, and to get over the negative reaction to the hype. XP is,
in fact, a highly disciplined and professional technique for
developing software.
| |
| Robert C. Martin 2004-03-26, 11:50 pm |
| On Fri, 19 Mar 2004 16:43:30 GMT, JXStern <JXSternChangeX2R@gte.net>
wrote:
>On Fri, 19 Mar 2004 08:07:45 -0500, "Universe"
><universe@tAkEcovadOuT.net> wrote:
>
>Jason,
>
>What Uni says. Everything you've said is about coding. This is all
>XP is about, and all that it contributes to the art and science of
>methodology. Now, before any XP'r denies this, you have to understand
>that IT IS A GOOD THING.
GOOD THING or not, it's simply incorrect. While it is true that many
of the XP practices are about how to write code; many others are about
how to estimate, plan, and manage a project.
>It is a fascinating and potentially crucial
>idea that coding first, last, and always might be the key to software
>development.
Fascinating as it may be, this is NOT the message of XP. Certainly XP
advocates coding early and often; but "first, last, and always" is a
gross overstatement, and blatantly false.
>Yeah, even from the beginning XP had some other stuff, but (outside of
>pair programming) nothing that others haven't said and done for
>decades. And, 99% of it conflicts with the basic idea of code, code,
>code, so frankly I can't even take it seriously as anything but
>defensive constructions around the major idea.
Interesting. /YOU/ seem to have defined XP as "code, code, code" and
so you disregard any practices in XP that do not support your
definition. Fortunately, those of us who practice XP do not disregard
those practices.
>I only speechify here because the thread is cross-posted into the XP
>newsgroup, which I have generally avoided since playing around there
>several years ago and never having a discussion there I found
>reasonable.
It seems feasible that this is because you strongly hold to your
incorrect preconceptions about XP despite all documentation and
discussion to the contrary.
| |
| Ronald E Jeffries 2004-03-26, 11:50 pm |
| On Fri, 19 Mar 2004 08:43:28 -0500, "Universe"
<universe@tAkEcovadOuT.net> wrote:
> Historically (the last ~3 years) most XP'ers and leading XP'er have
> EXPLICITLY denied that:
> we should always try to have an at least minimally complete overall
> (holistic) analysis of all key aspects before implementing the bulk,
> or logical high level design heart of a software project.
References, please?
--
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.
| |
| JXStern 2004-03-26, 11:50 pm |
| On Sat, 20 Mar 2004 00:40:16 -0600, Robert C. Martin
<unclebob@objectmentor.com> wrote:
>So, in fact, the release plan is in place before any significant
>development work is begun.
Excellent. But this is still about writing code, when the question on
the table was about not writing code.
>
>I don't believe that you have looked very closely at the XP materials.
>XP makes a big deal out of separating customer responsibilities and
>rights, from developer responsibilities and rights.
Yes, and I consider it to be entirely wrong-headed.
J.
| |
| JXStern 2004-03-26, 11:50 pm |
| On Sat, 20 Mar 2004 00:54:32 -0600, Robert C. Martin
<unclebob@objectmentor.com> wrote:
>
>GOOD THING or not, it's simply incorrect. While it is true that many
>of the XP practices are about how to write code; many others are about
>how to estimate, plan, and manage a project.
Robert, no matter what you say, I will consider something to be XP
only if it is X and P. All the rest is generic. The question is
always whether XP is better than some other methodology, not whether
XP is better triple-net than running around blindfold and naked.
J.
| |
| Jason Nocks 2004-03-26, 11:50 pm |
| JXStern wrote:
> On Sat, 20 Mar 2004 00:40:16 -0600, Robert C. Martin
> <unclebob@objectmentor.com> wrote:
>
>
> Excellent. But this is still about writing code, when the question on
> the table was about not writing code.
>
How is a release plan more about writing code than a functional scope or
design document?
Isn't a design document supposed to be discussing the design of a system
that is intended to be coded (implemented)? As Mr. Universe would say,
"... to implement ... what we know will shortly be incorporated".
Maybe the concept of an XP release plan is completely misunderstood
here. An XP release plan is about laying out what User Stories will be
included in upcoming iterations and/or releases. User Stories are
essentially user requirements.
So, an XP release planning session is conceptually similar to a
requirements planning phase in certain methodologies. What is different
is the length of time it takes and how often it is done. XP does not
have phases. XP release planning sessions are fairly brief and can occur
every iteration.
Now, please explain to me where you see the words *code* or *coding* in
the preceding 2 paragraphs.
>
>
> Yes, and I consider it to be entirely wrong-headed.
You asked above about "if a customer wants code written, I have never
seen any XP advice to recommend against it". Uncle Bob's response is a
direct refutal of your statement. Now you say that this is
"wrong-headed", whatever that means.
So, let me paraphrase.
JXStern: I don't like XP because it lets customers dictate what code is
written.
Uncle Bob: Actually, it doesn't.
JXStern: Yes, and that's wrong.
Please explain. Do you think that customers should be involved in making
technical decisions or not?
Or, are you objecting to the fact that XP allows the customer to decide
what features they wish to get in return for their investment?
Or, do you have some other point altogether?
>
> J.
>
Cheers,
Jason Nocks
SourceXtreme, Inc.
http://www.sourcextreme.com/
| |
| Jason Nocks 2004-03-26, 11:50 pm |
| JXStern wrote:
>
> Robert, no matter what you say, I will consider something to be XP
> only if it is X and P. All the rest is generic. The question is
> always whether XP is better than some other methodology, not whether
Maybe you are looking for a dogmatic approach. XP is generally not
presented as a "the one and only solution for all people" type of approach.
Most XP practioners I've talked to choose XP for themselves because it's
a good fit for them. YMMV.
> XP is better triple-net than running around blindfold and naked.
Iguana.
>
> J.
>
Cheers,
Jason Nocks
SourceXtreme, Inc.
http://www.sourcextreme.com/
| |
| Ronald E Jeffries 2004-03-26, 11:50 pm |
| On Sat, 20 Mar 2004 19:08:22 GMT, JXStern <JXSternChangeX2R@gte.net>
wrote:
>
>Yes, and I consider it to be entirely wrong-headed.
Please explain briefly what would be a better way to proceed. "Not
separating customer responsibilities and rights from developer
responsibilities and rights" doesn't help me much.
It seems that the customers surely must have the primary
responsibility for deciding which features should be in and which
should be out. Are you suggesting otherwise?
It seems to me that the programmers surely must have the primary
responsibility for the quality of the code and design. Are you
suggesting otherwise?
If the XP notion is entirely wrong-headed, what would be right-headed?
--
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.
| |
| JXStern 2004-03-26, 11:50 pm |
| Here's where this sub-thread started:
On Wed, 17 Mar 2004 11:36:55 -0500, "Universe"
<universe@tAkEcovadOuT.net> wrote:
>Often after minimally complete analysis the verdict is "Don't Code". Or
>a radically better and more elegant solution presents itself. XP'ers would
>hardly ever see either of these options.
You now ask:
>How is a release plan more about writing code than a functional scope or
>design document?
I agree that a "release plan", being a sorting and selection of user
storis, is XP's closest approach to a strategic decision about whether
the whole project should proceed. And yet, it is still a different
sort of exercise.
Comparing and contrasting "release plan" to more conventional scope
and design is another question. I could argue them either way.
To reinterpret the original point again, you sometimes want to have
the kind of "holistic" discussions Universe likes to sell. Something
like meta-user stories (that makes them particular and not holistic).
Block diagram stuff in UML talk.
This stuff falls outside *any* development methodology, pretty much by
definition.
>So, an XP release planning session is conceptually similar to a
>requirements planning phase in certain methodologies. What is different
>is the length of time it takes and how often it is done. XP does not
>have phases. XP release planning sessions are fairly brief and can occur
>every iteration.
>
>Now, please explain to me where you see the words *code* or *coding* in
>the preceding 2 paragraphs.
Iteration = coding. You're welcome.
>You asked above about "if a customer wants code written, I have never
>seen any XP advice to recommend against it". Uncle Bob's response is a
>direct refutal of your statement.
No it isn't. Having a discussion about what to code, is not the same
as deciding what not to code. Right now, I am not coding seventeen
million user stories. OK, I see the confusion. RCM willfully
misinterpreted my comment and I let it pass. RCM says XP does not let
customers dictate what /code/ to write. Aw, come on, guys. We're not
discussing whether we want the customer dictating variable names and
stuff, we're talking about whether the customer wants code written to
do X. The discussion here is what to do when the customer comes in
with a really bizarre idea. The best XP recommends is to lay out the
costs and let the user choose. This is an understandable position,
but I think it insufficient. I have been in these situations numerous
times. I've played them in various ways. I think XP errs in taking a
fixed position on it at all, some of these discussions are also
outside of methodology. Some kind of ethics or professionalism
guidelines may touch on them, but the situations are complex.
J.
| |
| JXStern 2004-03-26, 11:50 pm |
| On Sun, 21 Mar 2004 07:14:14 -0500, Ronald E Jeffries
<ronjeffries@acm.org> wrote:
>
>Please explain briefly what would be a better way to proceed. "Not
>separating customer responsibilities and rights from developer
>responsibilities and rights" doesn't help me much.
Respo | | |