Refactoring, requirements, and business value
Paul Sinnett
> impact of adding a new kind of employee until you had been forced to
> add a new kind of employee once. The rule is: "Second time pays for
> generality."
Agreed. Although in Refactoring, Martin Fowler suggests "three strikes
and you refactor". But that is beside the point. The point is not to
generalise until you need to.
>> The problem I have with your above requirement (restriction is a
>> better description because it doesn't require us to do something so
>> much as not do something else) is that it appears to offer us no
>> business value.
>
> The programmers have two imperatives: business value and code
> quality. These are orthogonal values and neither is sacrificed for
> the other. I will refactor systems to increase their quality without
> affecting business value.
>
> Of course we could argue that code quality has a huge impact upon
> business value -- and certainly this is true. However, I don't wish
> to turn control of code quality over to the business analysts. As a
> craftsman I have very high standards that I am not willing to
> compromise.
How does the customer know that what we present as essential refactoring
isn't simply programmer gold plating dressed up as quality? For that
matter, how do we know that we aren't deluding ourselves?
John Roth
"Paul Sinnett" <paul.s...@btinternet.com> wrote in message
news:3E4B10A...@btinternet.com...
Since you dropped what seems to be an ongoing discussion into the
XP group, could you supply a bit more background? I'm not sure where
the discussion came from with just this post.
Just on the basis of this, the XP viewpoint is that refactoring is not
optional, and it's not something the customer has anything to do with.
It's simply a cost of doing business. Over any reasonable time
frame, you'll spend about the same proportion of time refactoring
in order to maintain a reasonably constant level of design quality.
The big control on it is that you don't stop delivering business
value in each iteration because you decide some aspect of your
design s3s and half the classes need to be redone some other way.
You figure out a way to get from here to there piecemeal so you
can continue delivering value.
If you can't (and sometimes you really can't) you do present the
options to the customer, with the costs of doing it different ways.
When they see a steadily rising cost of implementing more functionality
if you don't take the time in the near future to make big changes,
most customers will be quite rational. They'll figure out where in
the overall plan it fits best. Whether they scream first is mostly
dependent on personality.
John Roth
>
>
Paul Sinnett
>>> quality. These are orthogonal values and neither is sacrificed
>>> for the other. I will refactor systems to increase their quality
>>> without affecting business value.
>>>
>>> Of course we could argue that code quality has a huge impact upon
>>> business value -- and certainly this is true. However, I don't
>>> wish to turn control of code quality over to the business
>>> analysts. As a craftsman I have very high standards that I am not
>>> willing to compromise.
>>
>> How does the customer know that what we present as essential
>> refactoring isn't simply programmer gold plating dressed up as
>> quality? For that matter, how do we know that we aren't deluding
>> ourselves?
>
> Since you dropped what seems to be an ongoing discussion into the XP
> group, could you supply a bit more background? I'm not sure where the
> discussion came from with just this post.
This is a from a discussion in comp.object about the motivations for
using polymorphism in programs. I cut this out since I thought it
brought up an interesting grey area specific to XP.
> Just on the basis of this, the XP viewpoint is that refactoring is
> not optional, and it's not something the customer has anything to do
> with. It's simply a cost of doing business. Over any reasonable time
> frame, you'll spend about the same proportion of time refactoring in
> order to maintain a reasonably constant level of design quality.
Indeed. The discussion stems from a "customer" requirement which appears
to direct the programmers to carry out certain refactorings:
> Once all this is working, make sure you can add new and different
> kinds of employees without changing the source modules that contain
> the current employees. No hint of any of these changes should show up
> in the initial module at the top of this post, or in any of the code
> that previously exists.
I say "customer" since I suspect this is a programmer talking.
Ron Jeffries
wrote:
>How does the customer know that what we present as essential refactoring
>isn't simply programmer gold plating dressed up as quality? For that
>matter, how do we know that we aren't deluding ourselves?
If your refactoring activities are so large as to have to be presented to your
customer, consider doing smaller, more continuous ones. Refactoring is like
formatting and using good names -- it should be how we program, not a second
pass.
--
Ronald E Jeffries
http://www.XProgramming.com
http://www.objectmentor.com
I'm giving the best advice I have. You get to decide whether it's true for you.
John Roth
"Paul Sinnett" <p...@coyotedev.com> wrote in message
news:3E4B75D3...@coyotedev.com...
If I drill down and do a bit of mind reading, the actual customer
requirement seems to be:
"I will be adding new kinds of employees in the future, and I don't want
to
pay too much for each one. Make it so."
What I'd do with a requirement like that is ask for a few examples
and then war game them against the current design to get a feeling
about how much effort it would take to implement each one.
That isn't a complete design effort - just enough to either get
a feeling of confidence, or flush out some risks that need to be
dealt with.
John Roth
John Roth
>
Paul Sinnett
>> direct the programmers to carry out certain refactorings:
>>
>>> Once all this is working, make sure you can add new and different
>>> kinds of employees without changing the source modules that
>>> contain the current employees. No hint of any of these changes
>>> should show up in the initial module at the top of this post, or
>>> in any of the code that previously exists.
>>
>> I say "customer" since I suspect this is a programmer talking.
>
> If I drill down and do a bit of mind reading, the actual customer
> requirement seems to be:
>
> "I will be adding new kinds of employees in the future, and I don't
> want to pay too much for each one. Make it so."
Sounds like a reasonable interpretation. And I know in XP we explicitly
prohibit this kind of speculative up front design on the programmer's
side. Are customers allowed to break the YAGNI rule in user stories?
If you think about it, the more you add new employees the easier it is
going to get anyway just through natural refactoring. I don't see why we
would need an explicit story such as this. Indeed it seems to me that
this would be a poor user story to try to implement since it forces the
programmers to break the YAGNI rule. What do you think?
John Roth
Explict stories like this come from bad experiances in the past.
And those bad experiances are legion.
I could go both ways on whether to do some up front work to make
adding more employee types easy. If the team is well experianced
on that kind of manouver, I'd just say do what they normally do. Look
at the story, and check if there are any red flags in the current design
(also known as risk analysis). If not, go ahead with normal development.
If they aren't practiced at it, there may be some real justification to
looking
at what would need to be done in the design in some detail. The basic
thing
is to avoid doing too much detailed analysis, and what is too much
depends
on the experiance of the team.
John Roth
>
Paul Sinnett
>> refactoring isn't simply programmer gold plating dressed up as
>> quality? For that matter, how do we know that we aren't deluding
>> ourselves?
>
> If your refactoring activities are so large as to have to be
> presented to your customer, consider doing smaller, more continuous
> ones. Refactoring is like formatting and using good names -- it
> should be how we program, not a second pass.
Quite. Good points. Although the context is a customer requiring a
certain design because he is thinking about requirements he might add at
a future date. In this case the customer is also a programmer (hence the
inside knowledge).
You also haven't addressed the questions asked above. For example should
we refactor code to make it easier to add things that we think we are
going to need in the future? That is what I mean by "gold plating"
within the context of the discussion.
Shayne Wissler
"John Roth" <john...@ameritech.net> wrote in message
news:v4m6n7s...@news.supernews.com...
> The big control on it is that you don't stop delivering business
> value in each iteration because you decide some aspect of your
> design s3s and half the classes need to be redone some other way.
> You figure out a way to get from here to there piecemeal so you
> can continue delivering value.
>
> If you can't (and sometimes you really can't) you do present the
> options to the customer, with the costs of doing it different ways.
> When they see a steadily rising cost of implementing more functionality
> if you don't take the time in the near future to make big changes,
> most customers will be quite rational. They'll figure out where in
> the overall plan it fits best. Whether they scream first is mostly
> dependent on personality.
Is the idea that there are times (other than "spikes") when you can't write
code that delivers business value official XP? What does it call those?
Spokes?
"XP works. Except when it doesn't."
Shayne Wissler
Ron Jeffries
wrote:
> > If your refactoring activities are so large as to have to be
> > presented to your customer, consider doing smaller, more continuous
> > ones. Refactoring is like formatting and using good names -- it
> > should be how we program, not a second pass.
>
>Quite. Good points. Although the context is a customer requiring a
>certain design because he is thinking about requirements he might add at
>a future date. In this case the customer is also a programmer (hence the
>inside knowledge).
>
>You also haven't addressed the questions asked above. For example should
>we refactor code to make it easier to add things that we think we are
>going to need in the future? That is what I mean by "gold plating"
>within the context of the discussion.
My answer is "yes", but I'll bet I don't mean what you think I mean. ;->
To make it easier to add things in the future, the best thing to do is to have
the code be perfectly modular for what it does today. Adding hooks takes more
time than making the code clean, and it is subject to error.
So yes, refactor code to make it easy to add things. Code that does that,
follows Beck's rules of simple code. In priority order, simple code:
1. Runs all the tests;
2. Contains no duplication;
3. Expresses all the ideas you had when writing it;
4. Minimizes the number of classes and methods.
I'd refactor to that state. No hooks. First time something needs hooked in,
that's when I'd build the hook.
Regards,
Universe
No one puts in unncessary code if not needed. However what you, Beck and
XP are pushing is "don't put design an overall system architecture that
will provide, one or more hooks you'll need for fuller implementation, or
implementation period in future releases."
And you all push creating non-holistic, less than optimal for future
implementation system designs (system architiectures) despite the fact
that a holistic, "future release capable" design is typically "cleaner",
more robust, more flexible, and more capable, both in the current release
to implement what will be done in future releases and also it paves the
way for a design having all those good things after implementing
what was anticipated in future releases.
I.e. you all are proponents of piecemeal, fly by the seat of your pants,
by and large resource wasting, higher potential for stovepipe design
evolution methods of software creation and system development. Hackery
pure and very simple.
Elliott
--
http://www.radix.net/~universe ~*~ Enjoy! ~*~
Hail OO Modelling! * Hail the Wireless Web!
@Elliott 2003 my comments ~ newsgroups+bitnet OK
Universe
[typo]
> Ron Jeffries wrote:
>> ...
>> I'd refactor to that state. No hooks. First time something needs hooked in,
>> that's when I'd build the hook.
> No one puts in unncessary code if not needed. However what you, Beck
> and XP are pushing is "don't *[]* design an overall system architecture
Paul Sinnett
>> think we are going to need in the future? That is what I mean by
>> "gold plating" within the context of the discussion.
>
> My answer is "yes", but I'll bet I don't mean what you think I mean.
> ;->
If your saying "yes" but you mean "no" perhaps you should consider
saying what you mean. :-)
> To make it easier to add things in the future, the best thing to do
> is to have the code be perfectly modular for what it does today.
> Adding hooks takes more time than making the code clean, and it is
> subject to error.
>
> So yes, refactor code to make it easy to add things. Code that does
> that, follows Beck's rules of simple code. In priority order, simple
> code:
>
> 1. Runs all the tests; 2. Contains no duplication; 3. Expresses all
> the ideas you had when writing it; 4. Minimizes the number of classes
> and methods.
>
> I'd refactor to that state. No hooks. First time something needs
> hooked in, that's when I'd build the hook.
Then your answer is "no". In the context of the question, gold plating
(to make it easier to add things) means adding the hooks you speak of.
It also means possibly adding more classes and methods than you need at
the moment.
An example in C++ would be making an abstract base class and overriding
it with 1 sub-class to make it easier to add new sub-classes in the
future. The hooks are the virtual function declarations and the base
class is not needed yet.
Was this not clear from the question?
John Roth
"Shayne Wissler" <thal...@yahoo.com> wrote in message
news:1rg3a.102904$2H6.1818@sccrnsc04...
You call that painting yourself into a corner. The more experiance you
have, and the more you stick to good practice, the less often that's
going to happen.
It takes time to paint a door on the wall, open it and walk through.
The easiest way to avoid painting yourself into a corner is to run a
full planning game as part of release planning for each release (unless
you're doing *really* frequent releases; then you do it on a quarterly
basis.) You do your risk analysis there where you've got all the known
stories on the table, and you can run war games against what the
customer thinks he *might* want to ask for down the road.
John Roth
> Shayne Wissler
>
>
>
Shayne Wissler
Ron Jeffries
wrote:
> >> ... should we refactor code to make it easier to add things that we
Paul, with all due respect, I trust that had I meant "no", I would have said
"no". The question was:
> >> ... should we refactor code to make it easier to add things that we
> >> think we are going to need in the future? That is what I mean by
> >> "gold plating" within the context of the discussion.
I would in fact /refactor/ code to make it easier to add things that I think
will be needed in the future. What I would /not/ do is to add features and hooks
to the code which are not needed today.
That's why my answer is "yes, I would refactor code to make change easier, but I
probably don't mean the same 'yes' as some people might expect."
Make sense?
Keith Ray
Ron Jeffries <ronje...@REMOVEacm.org> wrote:
> So yes, refactor code to make it easy to add things. Code that does that,
> follows Beck's rules of simple code. In priority order, simple code:
>
> 1. Runs all the tests;
> 2. Contains no duplication;
> 3. Expresses all the ideas you had when writing it;
> 4. Minimizes the number of classes and methods.
>
> I'd refactor to that state. No hooks. First time something needs hooked in,
> that's when I'd build the hook.
Sometimes there's a disagreement about "simple code".
For example, a singletons or global variables...
Passing an object around in parameter lists and/or constructors might be
perceived as "less simple" than global variables, but globals/singletons
can cause all sorts of problems for keeping track of state of an object,
and all sorts of problems for testing things in isolation.
A side benefit from not using globals is that it becomes easier to make
"more" of something that had been original thought of as "one" -- more
than one document open at a time, more than one server connected to at a
time, and so on... but you're not really planning for a future of making
multiple objects, you're just trying to make something testable and
understandable.
--
C. Keith Ray
Paul Sinnett
> have said "no".
Ron, with equal respect, if you're betting on the fact that I won't
understand your answers (as you stated earlier) you can hardly expect me
to believe that.
> I would in fact /refactor/ code to make it easier to add things that
> I think will be needed in the future. What I would /not/ do is to add
> features and hooks to the code which are not needed today.
>
> That's why my answer is "yes, I would refactor code to make change
> easier, but I probably don't mean the same 'yes' as some people might
> expect."
>
> Make sense?
None at all. Specifically, I cannot determine what you would or would
not do in the following case:
You have a class "Employee" in C++ to satisfy the requirements of the
current iteration. In the next iteration you think you will have to
differentiate between salaried employees and contractors.
If you make the class "Employee" an abstract base class and create a
sub-class "SalariedEmployee" it will be easier to add "Contractor" as
another sub-class in the next iteration. According to your first
statement in your paragraph above you would do this.
But if you did that you would be adding a class into the code which is
not needed for the current iteration. According to your second statement
in your paragraph above you would not do this.
Once again I ask you to use words in the way people might expect.
Ron Jeffries
wrote:
>> So yes, refactor code to make it easy to add things. Code that does that,
>> follows Beck's rules of simple code. In priority order, simple code:
>>
>> 1. Runs all the tests;
>> 2. Contains no duplication;
>> 3. Expresses all the ideas you had when writing it;
>> 4. Minimizes the number of classes and methods.
>>
>> I'd refactor to that state. No hooks. First time something needs hooked in,
>> that's when I'd build the hook.
>
>Sometimes there's a disagreement about "simple code".
Yes, though when I limit my thinking to the above four items, it helps make
issues more clear. In the final analysis, using whatever heuristics one has, one
must decide for oneself. I'm merely reporting what I do.
>
>For example, a singletons or global variables...
>
>Passing an object around in parameter lists and/or constructors might be
>perceived as "less simple" than global variables, but globals/singletons
>can cause all sorts of problems for keeping track of state of an object,
>and all sorts of problems for testing things in isolation.
>
>A side benefit from not using globals is that it becomes easier to make
>"more" of something that had been original thought of as "one" -- more
>than one document open at a time, more than one server connected to at a
>time, and so on... but you're not really planning for a future of making
>multiple objects, you're just trying to make something testable and
>understandable.
Yes. In general I avoid singletons and globals for the reasons you mention. In
the list of rules for simple code above, that comes primarily under item 3. If a
thing is being used as a parameter to a bunch of methods, rule 3 suggests
passing it as a parameter. This can get ugly, of course, but my tendency would
be away from singletons and globals.
Ron Jeffries
wrote:
> > Paul, with all due respect, I trust that had I meant "no", I would
> > have said "no".
>
>Ron, with equal respect, if you're betting on the fact that I won't
>understand your answers (as you stated earlier) you can hardly expect me
>to believe that.
I didn't say that you would not understand my answer. I said:
"My answer is "yes", but I'll bet I don't mean what you think I mean. ;->"
> > I would in fact /refactor/ code to make it easier to add things that
> > I think will be needed in the future. What I would /not/ do is to add
> > features and hooks to the code which are not needed today.
> >
> > That's why my answer is "yes, I would refactor code to make change
> > easier, but I probably don't mean the same 'yes' as some people might
> > expect."
> >
> > Make sense?
>
>None at all.
I'm sorry that what seems so simple to me does not seem so to you. I'll try
again.
>Specifically, I cannot determine what you would or would
>not do in the following case:
>
>You have a class "Employee" in C++ to satisfy the requirements of the
>current iteration. In the next iteration you think you will have to
>differentiate between salaried employees and contractors.
>
>If you make the class "Employee" an abstract base class and create a
>sub-class "SalariedEmployee" it will be easier to add "Contractor" as
>another sub-class in the next iteration. According to your first
>statement in your paragraph above you would do this.
I see no place in my words where I say I would add an abstract class, or
anything like it. I do refactor the code to be as appropriate as possible for
today's function. In my opinion, that's the best way to prepare code for
tomorrow.
As a rule, I would not in fact add an unneeded abstract class. I'm not sure
which paragraph you think implies that I would. In any case, I will not in
general add any code, abstract classes or other entities that are not necessary
to today's functionality.
Suppose we have a concrete class, Employee, as you describe. Suppose we
anticipate Contractor as a new entity but the curent requirements do not call
for it. We think that there should be an Abstract class Employee, and that our
current class should be SalariedEmployee.
First of all, we are speculating about the problem. We are speculating -- though
we can be pretty sure -- that we'll need to support Contractors. We have no such
need now. This suggests that we shouldn't work on that, but should instead work
on current needs. (But what if it is cheaper to do now, someone is about to ask.
I'll come back to that.)
Second, we are speculating about the solution. We don't know the Contractor
requirements as yet, and we certainly don't know the best solution to the
requirements that we don't have. In particular, the use of Strategy might be a
more appropriate way of representing the differences between contractors and
employees. It might be that there should be a common Interface that the two
share, but that they should not have a common Employee superclass.
Third, in the languages I use, subclassing is a card that can only be played
once for any class. I would therefore hold the subclassing card in my hand until
I was quite sure exactly where it is to be played.
So I find the idea of building the abstract and concrete classes to be premature
in this case, since there is only one concrete class in hand at this time.
But what about the notion that it will be cheaper now than it is later? I see no
reason to believe that it will be cheaper. The lines of code to be written in
the Employee hierarchy will be the same tomorrow as they are today. No savings
will accrue, even if we don't know any more tomorrow than we do today.
We might be concerned that there would be more places using the word "Employee"
that would have to be renamed to "SalariedEmployee", so that the edit would be
bigger. If the software all belongs to the team, then the way I work this
wouldn't be enough of an issue to induce me to make the abstract class, though
if the team thought "SalariedEmployee" was a better class name, I could support
changing that now because it makes the code express its intention better now.
Therefore, in summary, I would not implement the abstract class until a concrete
need arose. I have no use for an abstract class unless
a) I have two or more concrete classes to hang on it, or
b) I am exporting the software outside the project and expect its users to
need to subclass there. I'm taking it from the statement of the problem that we
have no such need in the present case.
>But if you did that you would be adding a class into the code which is
>not needed for the current iteration. According to your second statement
>in your paragraph above you would not do this.
I would not do this.
>
>Once again I ask you to use words in the way people might expect.
I'm doing my best, and I cannot know what you might expect. I'll be happy to try
to clarify what I'm saying whenever anyone has questions.
I refactor to create clean code for the current situation. In general I do not
add unused conceptual entities such as abstract classes, in anticipation of
future use. There could be exceptions to this general rule of mine, and I'd be
happy to discuss them if need be.
Regards,
Paul Sinnett
> I do not add unused conceptual entities such as abstract classes, in
> anticipation of future use. There could be exceptions to this general
> rule of mine, and I'd be happy to discuss them if need be.
At last an answer that I understand. Thanks Ron. (The fact that it has
taken us so long to reach it, and that in my version of the English
language this equates to the answer "no" whereas in yours it equates to
the answer "yes" is probably not a topic worth discussing in this
thread. I guess your brain must be too highly tuned to understand me. :-) )
So what would you say to a customer requirement that effectively forces
us, as programmers, into breaking that rule?:
> Once all this is working, make sure you can add new and different
> kinds of employees without changing the source modules that contain
> the current employees. No hint of any of these changes should show up
> in the initial module at the top of this post, or in any of the code
> that previously exists.
In other words, can customer requirements trump programmer refactoring
rules?
Shayne Wissler
"Ron Jeffries" <ronje...@REMOVEacm.org> wrote in message
news:s5ou4v4f3lsf06cc3...@4ax.com...
> First of all, we are speculating about the problem. We are speculating --
though
> we can be pretty sure -- that we'll need to support Contractors. We have
no such
> need now.
When you say that, do you mean that you're not aware of the requirement, or
only that it's not on today's cards? Or, do you think these are one in the
same? In your world, is any thought past today's cards "speculation"?
Certainly the situation could happen where the customer says "I absolutely
want Contractors support, but we'll add that feature next week. Today we're
just working on SalariedEmployee."
Shayne Wissler
Richard MacDonald
>
> "Ron Jeffries" <ronje...@REMOVEacm.org> wrote in message
> news:s5ou4v4f3lsf06cc3...@4ax.com...
>
>> First of all, we are speculating about the problem. We are
>> speculating --
> though
>> we can be pretty sure -- that we'll need to support Contractors. We
>> have
> no such
>> need now.
>
> When you say that, do you mean that you're not aware of the
> requirement, or only that it's not on today's cards? Or, do you think
> these are one in the same? In your world, is any thought past today's
> cards "speculation"?
(Speaking for myself, of course, not Ron :-)
While there is certainly much to be discussed here, in a word "no, yes,
yes, yes".
> Certainly the situation could happen where the customer says "I
> absolutely want Contractors support, but we'll add that feature next
> week. Today we're just working on SalariedEmployee."
Its more than the customer saying that, its that this is suggested as the
way to work. Even though you "know" that tomorrow things will change to
add Contractors, today you put on blinkers and work as if it won't.
This is a shocking thing. Its also a remarkable idea that each of us
should try for ourselves. I know personally it goes against my grain. I
also know that I've tried it and I find it superior the majority of the
time.
This may just be me. My tendency is to over-engineer, over-generalize,
and over-analyze, and wind up putting too much un-needed flexibility into
the model that is never used and is thus a burden during refactoring. It
usually happens that the flexibility I put in beforehand turns out to be
the wrong kind of flexibility and I then wind up undoing it in order to
go in a different direction. I do this over and over again. (And though I
say this may just be me, anyone who does not recognize at least a part of
this in themselves, you're probably a liar :-)
I've been working on this. I've been using parts of XP at times, and
other times I simply discipline myself to do the "simplest thing that can
possibly work" on the immediate problem. When I succeed, it can be a
profound experience. When I fail, so far its been because I was
undisciplined and did not trust the process, *not* that I programmed
myself into a corner (local optimum with an impossible hike over to the
next global optimum).
Honestly, I think the only way to be sold on (or to reject) this radical
idea is via personal experience. No amount of discussion can convey its
significance. All anyone can say is that some of the very best
programmers are swearing by it and that should be enough for you to try
it yourself to see if it works for you.
Also, it should go without saying (but probably needs to be said every
time) that there might be domains to which this does not apply. If you're
doing business programming with the typical moving target, its worth a
try. OTOH, if you've got a lenghy development cycle or are building a
library for general use, perhaps not.
John Roth
Even though it's presented as one, it's not a "customer" requirement
from an XP viewpoint, since it talks about the details of the program.
XP has a sufficiently strict separation of functions to warm the cockles
of an accountant's heart: customers talk about business needs, and
programmers deal with the programming stuff.
Since this talks about the programming stuff, someone violated the
separation of concerns.
John Roth
>
Shayne Wissler
"Richard MacDonald" <macdo...@worldnet.att.net> wrote in message
news:Xns932478E9C8577ma...@204.127.36.1...
> >> First of all, we are speculating about the problem. We are
> >> speculating --
> > though
> >> we can be pretty sure -- that we'll need to support Contractors. We
> >> have
> > no such
> >> need now.
> >
> > When you say that, do you mean that you're not aware of the
> > requirement, or only that it's not on today's cards? Or, do you think
> > these are one in the same? In your world, is any thought past today's
> > cards "speculation"?
>
> (Speaking for myself, of course, not Ron :-)
> While there is certainly much to be discussed here, in a word "no, yes,
> yes, yes".
That's what I would have guessed.
However, it is not speculation to recognize that a given feature is
absolutely required in order for the application to provide any business
value. Further, the customer-driven ordering here is arbitrary: he has no
way of knowing the ideal order to hand you features. The right way is to
identify all of the features that are absolutely essential, and have the
technical person order them in such a way as to optimize the development
velocity.
> > Certainly the situation could happen where the customer says "I
> > absolutely want Contractors support, but we'll add that feature next
> > week. Today we're just working on SalariedEmployee."
>
> Its more than the customer saying that, its that this is suggested as the
> way to work. Even though you "know" that tomorrow things will change to
> add Contractors, today you put on blinkers and work as if it won't.
Any methodology that advocates ignoring facts of reality is a poor one.
> This is a shocking thing. Its also a remarkable idea that each of us
> should try for ourselves. I know personally it goes against my grain. I
> also know that I've tried it and I find it superior the majority of the
> time.
Indeed, it may often be an improvement over the other (bad) alternative you
offer.
> This may just be me. My tendency is to over-engineer, over-generalize,
> and over-analyze, and wind up putting too much un-needed flexibility into
> the model that is never used and is thus a burden during refactoring. It
It is precisely someone with this sort of tendency who whose "pendulum" is
at risk for swinging to the other false alternative.
> usually happens that the flexibility I put in beforehand turns out to be
> the wrong kind of flexibility and I then wind up undoing it in order to
> go in a different direction. I do this over and over again. (And though I
> say this may just be me, anyone who does not recognize at least a part of
> this in themselves, you're probably a liar :-)
And if you claim that XP stops you from making mistakes, you're a liar. The
fact is that it pushes you toward making a different class of mistake.
You've traded one for another.
> I've been working on this. I've been using parts of XP at times, and
> other times I simply discipline myself to do the "simplest thing that can
> possibly work" on the immediate problem. When I succeed, it can be a
> profound experience. When I fail, so far its been because I was
> undisciplined and did not trust the process, *not* that I programmed
> myself into a corner (local optimum with an impossible hike over to the
> next global optimum).
Perhaps you're too willing to blame yourself, and not confident enough to
pursue your lack of comfort with XP.
No respectable process should require blind trust. If you're slipping into
another approach, it's probably because somewhere, in the back of your mind,
you're not comfortable, and you're not comfortable because deep down, you
realize that there's another way.
> Honestly, I think the only way to be sold on (or to reject) this radical
> idea is via personal experience. No amount of discussion can convey its
> significance.
Every programmer has already tried XP to some degree or other. I've had
customers hand me a subset of features, and have implemented a system true
to those, only to get some features later that force me to make changes that
would not have been necessary if the customer had told me the big picture
ahead of time (which is why I now take more care in requirements analysis).
> All anyone can say is that some of the very best
> programmers are swearing by it and that should be enough for you to try
> it yourself to see if it works for you.
Sounds like religion.
> Also, it should go without saying (but probably needs to be said every
> time) that there might be domains to which this does not apply. If you're
> doing business programming with the typical moving target, its worth a
> try. OTOH, if you've got a lenghy development cycle or are building a
> library for general use, perhaps not.
Of course, you're not an XPer. I wouldn't expect Philip to agree with this.
Shayne Wissler
Richard MacDonald
>
> "Richard MacDonald" <macdo...@worldnet.att.net> wrote in message
> news:Xns932478E9C8577ma...@204.127.36.1...
>
>> >> First of all, we are speculating about the problem. We are
>> >> speculating --
>> > though
>> >> we can be pretty sure -- that we'll need to support Contractors.
>> >> We have
>> > no such
>> >> need now.
>> >
>> > When you say that, do you mean that you're not aware of the
>> > requirement, or only that it's not on today's cards? Or, do you
>> > think these are one in the same? In your world, is any thought past
>> > today's cards "speculation"?
>>
>> (Speaking for myself, of course, not Ron :-)
>> While there is certainly much to be discussed here, in a word "no,
>> yes, yes, yes".
>
> That's what I would have guessed.
>
> However, it is not speculation to recognize that a given feature is
> absolutely required in order for the application to provide any
> business value.
True but irrelevant. Its not that the feature is absolutely required. Its
*when* that feature is absolutely required and, if its in the future,
whether any preparation should be done *now*.
> Further, the customer-driven ordering here is
> arbitrary: he has no way of knowing the ideal order to hand you
> features.
It may be arbitrary but its a darn fine arbitrariness, given the fact
that customer-developer communication mismatch is one of the biggest
problems facing a project.
> The right way is to identify all of the features that are
> absolutely essential, and have the technical person order them in such
> a way as to optimize the development velocity.
Nice if you can get it, but incorrect. The right way is to maximize ROI
for the customer. Period. That is often incompatible with your ideal. The
XP compromise is to make the release periods shorter, *then* optimize
within each period. IOW, stuff the global long-term optimum, go for the
stepwise optimum.
Can anyone deny this approach is reasonable, given the reality of moving
targets in the majority of business coding? I don't think so. However,
one can certainly identify situations when the incremental releases
aren't important and its only the final release that matters. Then the
discussion becomes interesting. FWIW, if the customer miscommunication
risk is low, I'd reject the dogmatic XP approach and take some chances
with a more extended project plan. But I wouldn't stray too far.
>> > Certainly the situation could happen where the customer says "I
>> > absolutely want Contractors support, but we'll add that feature
>> > next week. Today we're just working on SalariedEmployee."
>>
>> Its more than the customer saying that, its that this is suggested as
>> the way to work. Even though you "know" that tomorrow things will
>> change to add Contractors, today you put on blinkers and work as if
>> it won't.
>
> Any methodology that advocates ignoring facts of reality is a poor
> one.
That's such a bullshit interpretation I suspect you've missed what is
being said and/or have never had the experience yourself.
>> This is a shocking thing. Its also a remarkable idea that each of us
>> should try for ourselves. I know personally it goes against my grain.
>> I also know that I've tried it and I find it superior the majority of
>> the time.
>
> Indeed, it may often be an improvement over the other (bad)
> alternative you offer.
Nope, you've still missed the point. If you want to twist it around to
put your own preferences in your best light, be my guest. But you've
simply chosen to close your mind to what is being said.
>> This may just be me. My tendency is to over-engineer,
>> over-generalize, and over-analyze, and wind up putting too much
>> un-needed flexibility into the model that is never used and is thus a
>> burden during refactoring. It
>
> It is precisely someone with this sort of tendency who whose
> "pendulum" is at risk for swinging to the other false alternative.
Its not false, its better. Is it perfect? No. That's engineering, c'est
la vie.
>> usually happens that the flexibility I put in beforehand turns out to
>> be the wrong kind of flexibility and I then wind up undoing it in
>> order to go in a different direction. I do this over and over again.
>> (And though I say this may just be me, anyone who does not recognize
>> at least a part of this in themselves, you're probably a liar :-)
>
> And if you claim that XP stops you from making mistakes, you're a
> liar.
I don't claim this. I claim that my mistakes are less burdensome.
> The fact is that it pushes you toward making a different class
> of mistake. You've traded one for another.
Fair enough. As long as my new class of mistakes is better than my old
one, its worth it. Keep up a steady stream of small mistakes and before
you know it the project's a completed success :-)
>> I've been working on this. I've been using parts of XP at times, and
>> other times I simply discipline myself to do the "simplest thing that
>> can possibly work" on the immediate problem. When I succeed, it can
>> be a profound experience. When I fail, so far its been because I was
>> undisciplined and did not trust the process, *not* that I programmed
>> myself into a corner (local optimum with an impossible hike over to
>> the next global optimum).
>
> Perhaps you're too willing to blame yourself, and not confident enough
> to pursue your lack of comfort with XP.
Nope, XP may have suggested some things but I don't adopt approaches
whole, I adopt certain parts and adapt them. I could care less about the
"XP way". I do care about approaches that improve my work. All I am
saying is that this "simplest thing that can possibly work" approach
(sttcpw) is far more profound than it first appears and should be
experienced to be appreciated. PS: It doesn't mean "do the first stupid
thing that comes to mind". To me, it means "do the *right* thing and do
it as simply as possible." The former part of that is a fundamental to
any methodology (and something XP takes for granted, btw). The latter
part is the really neat idea, and its effect on one's code is the really
interesting thing worth investigating for oneself.
Let me enlarge on the impact of that. Last year my company applied this
philosophy during a rewrite of our flagship product. (Actually our best
developer took himself off for a while and did it solo.) He reduced the
number of classes by a factor of 20. He used case-statements, he used
non-OO concepts, he chose simple procedural over the "elegant" OO
alternative(s). Its a night and day improvement. (Please note: Its *not*
that the former version was badly written, its just that it was over-
engineered and we eventually realized that all our "foresight" was never
used.) Using sttcpw, we saw improvements in our productivity over a week.
We saw improvements modifying code written months ago. (Note: We refactor
all the time.) We have even reconsidered our devotion to OO. All from
trying "simplest thing that could possibly work" and observing where it
led us to.
> No respectable process should require blind trust. If you're slipping
> into another approach, it's probably because somewhere, in the back of
> your mind, you're not comfortable, and you're not comfortable because
> deep down, you realize that there's another way.
You sound like you've never had any bad habits you needed to correct.
>> Honestly, I think the only way to be sold on (or to reject) this
>> radical idea is via personal experience. No amount of discussion can
>> convey its significance.
>
> Every programmer has already tried XP to some degree or other. I've
> had customers hand me a subset of features, and have implemented a
> system true to those, only to get some features later that force me to
> make changes that would not have been necessary if the customer had
> told me the big picture ahead of time (which is why I now take more
> care in requirements analysis).
I agree entirely with this. I'm a big picture person myself. But its not
about ignoring the big picture. Its about *pretending* to ignore the big
picture *while* you're working on one small piece. This probably seems
crazy, or rather it probably seems contradictory and wrong-headed to you,
but its absolutely not. Rather, it frees the mind to develop better code
*now*, and the nice discover is these small optimum steps seem to also
provide an easier path to the ultimate best-code, big-picture optimum.
And again, this works for me personally, because one of my traps is
becoming paralyzed when faced with a multitude of options and fuzziness
that sometimes comes when trying to determine the best approach that fits
into the big picture. Perhaps that is a personal thing, but I've observed
that its a pretty universal personal thing. And when I wrote "When I
fail, so far its been because I was undisciplined and did not trust the
process" I was referring specifically to these times when I became unable
to continue coding while I tried to work out the big picture issues. The
best programmer I know is great because he is able to focus supremely on
the micro-issue at hand, instead of *simultaneously* trying to develop
the best overall approach, which runs the great risk of freezing, then
being wrong anyway.
>> All anyone can say is that some of the very best
>> programmers are swearing by it and that should be enough for you to
>> try it yourself to see if it works for you.
>
> Sounds like religion.
If 99% of the best golfers in the world all say: "I score better when I
keep my head still", is it religion to think I should try it for myself?
And if I try it and my scores improve, am I religious to continue to do
it? I won't believe in God until God talks to me personally. But once God
speaks, I'm a believer.
>> Also, it should go without saying (but probably needs to be said
>> every time) that there might be domains to which this does not apply.
>> If you're doing business programming with the typical moving target,
>> its worth a try. OTOH, if you've got a lenghy development cycle or
>> are building a library for general use, perhaps not.
>
> Of course, you're not an XPer. I wouldn't expect Philip to agree with
> this.
Its Phlip and its true he has never seen a domain he couldn't XPify. But
the XPers don't claim XP solves world hunger; they just say it works in
the domains they have tried. Its only the intentional mis-interpreters
who read this as claiming it works universally.
Guillermo Schwarz
"Ron Jeffries" <ronje...@REMOVEacm.org> escribió en el mensaje
news:dd6n4v4b62vuubv67...@4ax.com...
> On Thu, 13 Feb 2003 03:27:40 +0000, Paul Sinnett
<paul.s...@btinternet.com>
> wrote:
>
> >How does the customer know that what we present as essential refactoring
> >isn't simply programmer gold plating dressed up as quality? For that
> >matter, how do we know that we aren't deluding ourselves?
>
> If your refactoring activities are so large as to have to be presented to
your
> customer, consider doing smaller, more continuous ones. Refactoring is
like
> formatting and using good names -- it should be how we program, not a
second
> pass.
Sure, but what if you arrive late to a project? Then you probably have to
deal with arcane code that has several smells. You can fix some in your
spare time, but if you really want to eliminate the smells, you would need
to spend several weeks, no customer would pay for that.
What would you recommend in that case? Doing smaller refactories sounds
good, but you want be able to add the new functionality with confidence
unless the smell is removed and all the missing tests are created. You don't
have time to do that even if you refactor a little bit every now and then.
Guillermo Schwarz
"Universe" <univ...@radixundo.net> escribió en el mensaje
news:b2kivd$lpr$1...@news1.radix.net...
No one? Are you sure about that?
> However what you, Beck and
> XP are pushing is "don't put design an overall system architecture that
> will provide, one or more hooks you'll need for fuller implementation, or
> implementation period in future releases."
No, what they are saying is that you shouldn't add hooks if you are not
using them. If you need to use them now, add the hooks. If you will use them
later, then add them later. Do you really think it will be harder to do it
later? Then your code is not clear enough.
>
> And you all push creating non-holistic, less than optimal for future
> implementation system designs (system architiectures) despite the fact
> that a holistic, "future release capable" design is typically "cleaner",
> more robust, more flexible, and more capable, both in the current release
> to implement what will be done in future releases and also it paves the
> way for a design having all those good things after implementing
> what was anticipated in future releases.
Can you show us an example?
Did SMTP have hooks for adding new functionality when it was created? Did it
have MIME support or it was added later?
>
> I.e. you all are proponents of piecemeal, fly by the seat of your pants,
> by and large resource wasting, higher potential for stovepipe design
> evolution methods of software creation and system development. Hackery
> pure and very simple.
Hackery it would be if the code was not clear enough. It seems you have
never met a clear piece of code in your life.
Paul Sinnett
>> refactoring rules?
>
> Even though it's presented as one, it's not a "customer" requirement
> from an XP viewpoint, since it talks about the details of the
> program. XP has a sufficiently strict separation of functions to warm
> the cockles of an accountant's heart: customers talk about business
> needs, and programmers deal with the programming stuff.
>
> Since this talks about the programming stuff, someone violated the
> separation of concerns.
Ah yes. This was my first concern. When I called Bob on this he admitted:
> In the above scenario you wouldn't really refactor to minimize the
> impact of adding a new kind of employee until you had been forced to
> add a new kind of employee once. The rule is: "Second time pays for
> generality."
But then went on to present his pre factoring as a code quality issue
(at least that is how it reads to me in context). And that is where I
decided to widen the discussion to the XP group:
>> The problem I have with your above requirement (restriction is a
>> better description because it doesn't require us to do something so
>> much as not do something else) is that it appears to offer us no
>> business value.
>
> The programmers have two imperatives: business value and code
> quality. These are orthogonal values and neither is sacrificed for
> the other. I will refactor systems to increase their quality without
> affecting business value.
>
> Of course we could argue that code quality has a huge impact upon
> business value -- and certainly this is true. However, I don't wish
> to turn control of code quality over to the business analysts. As a
> craftsman I have very high standards that I am not willing to
> compromise.
To me the phrases quoted above smell like justifications for programmer
gold plating.
Ron Jeffries
wrote:
>At last an answer that I understand. Thanks Ron. (The fact that it has
>taken us so long to reach it, and that in my version of the English
>language this equates to the answer "no" whereas in yours it equates to
>the answer "yes" is probably not a topic worth discussing in this
>thread. I guess your brain must be too highly tuned to understand me. :-) )
>
>So what would you say to a customer requirement that effectively forces
>us, as programmers, into breaking that rule?:
>
> > Once all this is working, make sure you can add new and different
> > kinds of employees without changing the source modules that contain
> > the current employees. No hint of any of these changes should show up
> > in the initial module at the top of this post, or in any of the code
> > that previously exists.
>
>In other words, can customer requirements trump programmer refactoring
>rules?
To me, it sounds like the equivalent of a customer requirement to write bad
code. Probably you have something else in mind, but I'm not sure what kind of
customer requirement would do that. Can you give an example?
Ron Jeffries
>"Ron Jeffries" <ronje...@REMOVEacm.org> wrote in message
>news:s5ou4v4f3lsf06cc3...@4ax.com...
>
>> First of all, we are speculating about the problem. We are speculating --
>though
>> we can be pretty sure -- that we'll need to support Contractors. We have
>no such
>> need now.
>
>When you say that, do you mean that you're not aware of the requirement, or
>only that it's not on today's cards? Or, do you think these are one in the
>same? In your world, is any thought past today's cards "speculation"?
I am all in favor of thinking. My practice for /implementation/ is to implement
well-factored code for the requirements presently in the system. My experience
is that this results in code which is well-suited to the future.
But I'm all in favor of thinking, and I certainly can't prove that thinking
about what might happen may be influencing the choices I make.
>
>Certainly the situation could happen where the customer says "I absolutely
>want Contractors support, but we'll add that feature next week. Today we're
>just working on SalariedEmployee."
Yes. If we are just doing salaried employees this week, I would implement, to
the best of my ability, only code addressing Salaried Employees, and not
Contractors. Done in a well-factored fashion, I'm confident, based on lots of
experience doing things that way, that the necessary changes would go in just
fine when the time comes.
Ron Jeffries
>> > When you say that, do you mean that you're not aware of the
>> > requirement, or only that it's not on today's cards? Or, do you think
>> > these are one in the same? In your world, is any thought past today's
>> > cards "speculation"?
>>
>> (Speaking for myself, of course, not Ron :-)
>> While there is certainly much to be discussed here, in a word "no, yes,
>> yes, yes".
>
>That's what I would have guessed.
>
>However, it is not speculation to recognize that a given feature is
>absolutely required in order for the application to provide any business
>value. Further, the customer-driven ordering here is arbitrary: he has no
>way of knowing the ideal order to hand you features. The right way is to
>identify all of the features that are absolutely essential, and have the
>technical person order them in such a way as to optimize the development
>velocity.
That is one way to go, and it might be a right way. My experience, having worked
both ways, is that the order of implementation of features has a very small
effect, if any, on the overall time of development.
More important, however, is that my practice is to deliver useful, tested,
running software to the customer quite frequently. If I were only shipping once,
at the end of a year, I might do something different (although I don't think
so). But when I'm shipping every two weeks, I find that clean, well-factored
code, focused on what the customer wants right now, works fine, does not get
into design trouble, and most important to me, builds customer confidence.
I have worked both ways, and prefer incremental development using simple design
with refactoring.
Ron Jeffries
In circumstances where no one will pay for a big batch or rework, as you
suggest, I'm left with no choice other than to refactor little by little. So one
proceeds carefully, testing where possible, improving the code where possible.
My approach would be to find a balance between new features, new tests, and
cleaner code. I imagine that would be most everyone's approach. It's difficult.
I suspect you are as good at it, or better than I am.
Shayne Wissler
> > Indeed, it may often be an improvement over the other (bad)
> > alternative you offer.
>
> Nope, you've still missed the point. If you want to twist it around to
> put your own preferences in your best light, be my guest. But you've
> simply chosen to close your mind to what is being said.
Oh really? So what alternative is it that I have in mind?
Shayne Wissler
"Ron Jeffries" <ronje...@REMOVEacm.org> wrote in message
> On Sun, 16 Feb 2003 16:35:51 GMT, "Shayne Wissler" <thal...@yahoo.com>
wrote:
>
> >"Ron Jeffries" <ronje...@REMOVEacm.org> wrote in message
> >news:s5ou4v4f3lsf06cc3...@4ax.com...
> >
> >> First of all, we are speculating about the problem. We are
speculating --
> >though
> >> we can be pretty sure -- that we'll need to support Contractors. We
have
> >no such
> >> need now.
> >
> >When you say that, do you mean that you're not aware of the requirement,
or
> >only that it's not on today's cards? Or, do you think these are one in
the
> >same? In your world, is any thought past today's cards "speculation"?
>
> I am all in favor of thinking. My practice for /implementation/ is to
implement
> well-factored code for the requirements presently in the system. My
experience
> is that this results in code which is well-suited to the future.
>
> But I'm all in favor of thinking, and I certainly can't prove that
thinking
> about what might happen may be influencing the choices I make.
That's an honest comment. I wonder if you recognize all of the ramifications
of it. I guess you must or you wouldn't have said it in this context.
Shayne Wissler
Richard MacDonald
Shayne Wissler
Act your age.
Richard MacDonald
I no longer pretend I know what's in your head, at least in writing. Last
time I did that, you were rude. I learned my mistake. I won't fall for
stupid sucker bait questions again. The above was a stupid sucker bait
question.
I've also learned that your 3 step program is: (1) reject all as stupid,
(2) hint that you have something better, (3) refuse to say what it is
when asked. So I'm really not even trying to extract whatever preferences
you have, I'm simply saying something I have learned is important and
noting that you're not seeing it because you preferred a rhetorical dig
instead. Whether that is because you've (1) never experienced it, (2)
experienced it and know something better, or (3) so into your rhetorical
games you just missed it, whatever. The evidence points to (1) and (3),
from where I'm standing.
(Note: If you were actually going somewhere interesting with that
question, blame it on the boy who cried wolf.)
Ron Jeffries
<macdo...@worldnet.att.net> wrote:
>I no longer pretend I know what's in your head, at least in writing. Last
>time I did that, you were rude. I learned my mistake. I won't fall for
>stupid sucker bait questions again. The above was a stupid sucker bait
>question.
Richard: you have defined your problem exactly. It's a troll. A very good one,
we all fall into his trap from time to time. We all wind up in the same place.
He is backing in circles, snapping back once in a while. Nothing to offer, not
listening to answers.
Maybe it's just your turn. ;->
Tim Ottinger
> PS: It doesn't mean "do the first stupid
> thing that comes to mind". To me, it means "do the *right* thing and do
> it as simply as possible." The former part of that is a fundamental to
> any methodology (and something XP takes for granted, btw). The latter
> part is the really neat idea, and its effect on one's code is the really
> interesting thing worth investigating for oneself.
We probably need an alternative to FAQ, maybe MFM? for Most Frequent
Misinterpretation.
People confuse "simple" with "easy" or "quick". I don't see anyplace
where XP says to take the shortest shortcut to getting the code written,
but it definitely says to keep the current design the /simplest/ it can
be, where /simple/ is a quality of the design, no a measurement of the
programmer's time or effort.
I've adopted this enough to find it is right, even with the simplest way
doesn't use any OO or any Patterns or any other of the goodness we have
available to us. A "good design" is a simple design that works.
Tim
Jim Sontag
>
> Then your answer is "no". In the context of the question, gold plating
> (to make it easier to add things) means adding the hooks you speak of.
> It also means possibly adding more classes and methods than you need at
> the moment.
>
> An example in C++ would be making an abstract base class and overriding
> it with 1 sub-class to make it easier to add new sub-classes in the
> future. The hooks are the virtual function declarations and the base
> class is not needed yet.
>
IMHO, this would certainly qualify as gold plating. I also
find it plausible that a customer (or master) might ask for
this.
This is a speculative benefit. You have every right to ask
why they want this. You also have the responsibility to
point out, with proper OO languages and design, that the
effort to make a class abstract for a single subclass is
virtually the same in the future as it is in the present.
Leaving out the fact that You May Never Need it, the NPV of
the task is greater if left deferred. But the master must
be served.
Shayne Wissler
> >> >> > Indeed, it may often be an improvement over the other (bad)
> >> >> > alternative you offer.
> >> >>
> >> >> Nope, you've still missed the point. If you want to twist it
> >> >> around to put your own preferences in your best light, be my
> >> >> guest. But you've simply chosen to close your mind to what is
> >> >> being said.
> >> >
> >> > Oh really? So what alternative is it that I have in mind?
> >>
> >> Don't you know?
> >
> > Act your age.
>
> I no longer pretend I know what's in your head, at least in writing. Last
Oh, so now you admit that you've pretended to know? You're being more honest
with yourself nowadays. Keep it up and you just might be tolerable.
> time I did that, you were rude. I learned my mistake. I won't fall for
> stupid sucker bait questions again. The above was a stupid sucker bait
> question.
No, it was a sarcastic question based on your laughable presumption that you
know what I'm thinking before I write it.
> I've also learned that your 3 step program is: (1) reject all as stupid,
> (2) hint that you have something better, (3) refuse to say what it is
> when asked.
You're just making excuses for yourself (as well as showing off your
arrogant presumptuousness again). As a matter of fact, I've posted
extensively on the software process I use. You just have a selective memory
strongly conditioned by your personal biases.
Shayne Wissler
"Ron Jeffries" <ronje...@REMOVEacm.org> wrote in message
> On Mon, 17 Feb 2003 07:09:05 GMT, Richard MacDonald
> <macdo...@worldnet.att.net> wrote:
>
> >I no longer pretend I know what's in your head, at least in writing. Last
> >time I did that, you were rude. I learned my mistake. I won't fall for
> >stupid sucker bait questions again. The above was a stupid sucker bait
> >question.
>
> Richard: you have defined your problem exactly. It's a troll. A very good
one,
> we all fall into his trap from time to time. We all wind up in the same
place.
> He is backing in circles, snapping back once in a while.
Yes, we are going in circles. Every time I try to get into a technical
discussion with XPers, I end up receiving various ad hominems. You guys act
just like religious zealots when faced with science. You start calling the
scientist names.
> Nothing to offer, not listening to answers.
I remember having an extensive discussion with you and some other XPers
about the meaning of business value. I also remember posting an alternative
process to XP, one that's still iterative, but prioritizes things
differently. Now, just because you choose to not remember any of it, doesn't
mean I didn't offer it.
So I don't believe that the first part of your statement here is sincere.
You're only happy when giving out your own advice.
Keith Ray
Jim Sontag <ca....@jim.sontag> wrote:
[...]
> > An example in C++ would be making an abstract base class and overriding
> > it with 1 sub-class to make it easier to add new sub-classes in the
> > future. The hooks are the virtual function declarations and the base
> > class is not needed yet.
> >
>
> IMHO, this would certainly qualify as gold plating. I also
> find it plausible that a customer (or master) might ask for
> this.
In a C++ the private members of a class are normally "exposed" to the
compiler because they are declared in the same header file. Even though
declared private, they contribute to physical coupling, by requiring the
inclusion of headers for the declared classes of the private variables
(assuming the private members are not pointers or references whose types
could be forward-declared).
In a large project [see "Large-Scale C++ Design" by Lakos] this can
significantly slow down compilation time, as headers unneeded by clients
of your class get parsed simply so that the compiler knows the size of
the class's private members.
When compilation speed becomes a problem, two solutions exist for
"hiding" the private data declarations.
One is called the "pImpl" idiom, where a forward declaration to a
undeclared structure is put into the header, the private member data is
replaced by a pointer to this structure, the structure is declared in
the .cpp file to contain the private member data, and the constructor
and destructor allocate and free the private member structure (or you
use auto_ptr or shared_ptr to do that allocate and free for you.)
I don't recall a name for the other technique [Cocoa/NextStep has a
similar concept called "class clusters"], but it works like this: the
only class .h file included by clients of the class is one that is not
concrete -- not necessarily full of pure virtual functions, but not
intended to be instantiated. Instead of public constructors, declare
static member functions that allocate a subclass instantiation of this
abstract class. That subclass could be declared in the .cpp file, and it
contains the private member declarations.
An example of Cocoa's "class clusters" is the NSString class. It may
actually be fronting for several concrete subclasses, but no one has to
know about those subclasses. You call class ("static") methods to
allocate a NSString (subclass) and don't have to worry if the NSString
subclass is actually one specialized for Unicode, Ascii, SJIS, etc., or
even a 'container' subclass that contains instances of the Unicode,
Ascii, and SJIS subclasses as needed.
My point is that on a large project, making an abstract base class and
overriding it with one sub-class might practiced as part of the
necessity of keeping compilation times down, and therefore not be
gold-plating.
--
C. Keith Ray
Jeremy Dunck
<thal...@yahoo.com> wrote:
<snip>
>Yes, we are going in circles. Every time I try to get into a technical
>discussion with XPers, I end up receiving various ad hominems. You guys act
>just like religious zealots when faced with science. You start calling the
>scientist names.
Shane, while I have a tendency to believe software development is more
craft than science, I am interested in ways to predictably improve the
results.
No doubt my belief that it's not a science is influenced by my vested
interest in a non-automated development industry. I recognize this,
and admit that the truth may differ from my belief.
Please note I don't know the history of your involvement with this
group, so forgive me for not realizing that your frustration is rooted
in having already tried extensively to share your better way, to no
avail.
I have two suggestions:
1) Only tell people what they can hear. What I mean is--- if you're
talking to a CEO of a public corporation, espousing all the reasons
that corporate power must be reduced for a better democracy is very
likely not going to convince her, no matter how great your argument
is. Having an open mind on a particular topic is a prerequisite to
changing that mind.
I don't think that everyone in the XP group has a closed mind,
but neither can you expect to convince all (or even most) of the
people here to your point of view. You might convince some, though.
2) Given the little context I have, your anger and frustration only
diminish your argument. I am willing to be convinced, but calling Mr.
Jeffries a zealot is not likely to do that.
I do understand that when you're quite outnumbered, getting
defensive is natural. And certainly, the view you hold is in the
minority of this audience. I only point these two things out to try
to help you be more convincing.
Consider that the people you stand the best chance of
convincing are the same people that don't know the long history you
may have with the group. That is, those least invested in XP's
methodology.
Note that this isn't the same as saying that XP is for fools,
or that people that believe in XP are closed-minded. The fact is that
someone who has invested a lot in a particular idea probably has done
so because they are convinced of its merits. Those invested in XP are
no different.
I'm not trying to dissuade you from sharing your views, but
suggest that you realize you're talking to the believers, and you're
not terribly likely to convince them it doesn't work (or work well),
or that the people they have grow to respect and trust are idiots and
liars.
Work on convincing them why your way is better, and do so
without attacking some of the more recognized leaders in this group.
Doing otherwise is futile-- and that's not a fault of this
group or its believers. it's a facet of human nature.
If you'd like anecdotal evidence of this, go try to convince
the audience of a biology group that creationism is the Truth, or a
history group that it wasn't actually Homer that wrote the Iliad, but
his long lost brother Fred.
Faith in reason is a noble belief, and one I happen to share.
We have faith in something. Faith in reason and science is as much a
religion as any.
It is a common failing to believe that anyone that doesn't see
your point of view (which is based in reason) must therefore not share
your faith in reason. Instead, consider how your message could be
clearer, why they can't hear you, and what you might do to bring them
around.
Perhaps one thing reason has going for it is that it
demonstrably works. A proof always works, unless an axiom is later
disproven. Other religions are less demonstrative.
Don't attack someone for being religious; give them something
that works and the people with open minds (the only ones you'll ever
reach) will see it, and hear you.
>> Nothing to offer, not listening to answers.
>
>I remember having an extensive discussion with you and some other XPers
>about the meaning of business value. I also remember posting an alternative
>process to XP, one that's still iterative, but prioritizes things
>differently. Now, just because you choose to not remember any of it, doesn't
>mean I didn't offer it.
<snip>
As I've said, I don't know that history. Is there a Google News link
you could share to relevant threads?
HTH (me as much as you),
Jeremy
Richard MacDonald
Well there goes another good thread down the toilette.
Ron Jeffries
<jeremy.remove....@dunck.us> wrote:
> I'm not trying to dissuade you from sharing your views, but
>suggest that you realize you're talking to the believers, and you're
>not terribly likely to convince them it doesn't work (or work well),
>or that the people they have grow to respect and trust are idiots and
>liars.
Jeremy: We all fall into the trap of asking him to share his views. If you'll
review any of the threads, you'll see that they all have the same pattern. No
real views ever emerge. No real discussion ever emerges.
I welcome sensible professional discussion, here and elsewhere. I even enjoy
spirited argumentation. But there's no "there" there, with him.
Regards,
Shayne Wissler
Yep. If we could just get you and a few others to stop turning technical
discussions into your own personal platforms for launching personal
attacks, this ng would be a lot more interesting.
As it is, you people essentially censor any interesting disagreement by
usurping the topic by switching it--from discussion of the issue at hand to
name-calling and psychologizing. You do it again, and again, and again, and
the sad thing is that half the time I don't even think you realize it.
We've all been witness to your whining about the quality of this ng. Why
don't you put your money where your mouth is: the next time you disagree on
a technical point, demonstrate your maturity and speak to that. Don't
embarass yourself by attacking the person you disagree with. Attack the
idea if it's wrong, through demonstration. Don't commit ad hominem
fallacies every other paragraph and leave us with a bunch of empty but
unsubstantiated assertions.
And--if you really want to keep this civil and intellectual--stop putting
words in my mouth. You are neither authorized nor qualified to speak for
me.
Shayne Wissler
Paul Campbell
"Richard MacDonald" <macdo...@worldnet.att.net> wrote in message news:Xns932478E9C8577ma...@204.127.36.1...
> Also, it should go without saying (but probably needs to be said every
> time) that there might be domains to which this does not apply. If you're
> doing business programming with the typical moving target, its worth a
> try. OTOH, if you've got a lenghy development cycle or are building a
> library for general use, perhaps not.
There are engineering domains where it doesnt apply. On my current project
I was told "in 2 years time this system must manage 200 network nodes,
but for now 2 or 3 would be fine". Do I ignore this expressly stated future
scalability requirement ?? - not on your life. Actually I do start with a
simple architecture and plan to refactor it maybe once or twice but I have
a definite road map based on the final large scale deployment in mind
throughout.
Simplest Thing That Works avoids unnecessary pre-planning in the same
way that automatic jailing of all murder suspects without trial avoids the
danger of allowing a genuine murderer to go free.
> All anyone can say is that some of the very best
> programmers are swearing by it and that should be enough for you to try
> it yourself to see if it works for you.
I can see the appeal - it allows one to abdicate real responsibility for optimal
return on developement investment over the life of a project and get on with the
"real work" or programming knowing that you are beyond reproach.
Paul C.
Phlip
> When you say that, do you mean that you're not aware of the requirement,
> or only that it's not on today's cards? Or, do you think these are one in
> the same? In your world, is any thought past today's cards "speculation"?
>
> Certainly the situation could happen where the customer says "I absolutely
> want Contractors support, but we'll add that feature next week. Today
> we're just working on SalariedEmployee."
Objection: Asked and answered.
--
Phlip
http://www.greencheese.org/HoneySatellite
-- In the future everyone will be Andy Warhol for 15 minutes --
Ron Jeffries
<p.au.l.ca...@ob.jectvi.sion.c.o.u.k> wrote:
>There are engineering domains where it doesnt apply. On my current project
>I was told "in 2 years time this system must manage 200 network nodes,
>but for now 2 or 3 would be fine". Do I ignore this expressly stated future
>scalability requirement ?? - not on your life. Actually I do start with a
>simple architecture and plan to refactor it maybe once or twice but I have
>a definite road map based on the final large scale deployment in mind
>throughout.
>
>Simplest Thing That Works avoids unnecessary pre-planning in the same
>way that automatic jailing of all murder suspects without trial avoids the
>danger of allowing a genuine murderer to go free.
>
>> All anyone can say is that some of the very best
>> programmers are swearing by it and that should be enough for you to try
>> it yourself to see if it works for you.
>
>I can see the appeal - it allows one to abdicate real responsibility for optimal
>return on developement investment over the life of a project and get on with the
>"real work" or programming knowing that you are beyond reproach.
Actually there is no suggestion of abdicating real responsibility in XP. I'm
rather surprised that you might think that anyone could seriously offer such
advice. And XP faces us with our mistakes, day in and day out, which tends to
get one over any notion that one is beyond reproach.
I'd like to remind the reader of the two formulations of the "simplest" mantra,
and then to discuss how I use my version in actual work. And I'd like to invite
you, Paul, and anyone, to explore what might go wrong in the 200 vs 3 node case,
if one followed the practice I'll describe.
Kent Beck, faced with the question of "how should we implement this," asks "what
is the simplest thing that could possibly work?" This question focuses us on two
important matters: First, doing what could possibly work, not what couldn't.
Second, focusing on simplicity within that context.
I formulated the rule "Do the simplest thing that could possibly work," which is
more radical than Kent's question. Having answered the question "what is", my
practice is to go ahead with the simplest solution remaining. So far, that
practice has not gotten me in trouble, and I'll describe a bit about why just
below.
Now offhand I don't know what would be different in the way I would manage 200
nodes instead of three, so it would be helpful if you would say what you would
do differently in a program for a few and a program for many. Then we might have
an interesting discussion of how to get there.
Here's what happens when I work in my preferred mode, "Do the simplest thing
that could possibly work."
1. I think of some possible solutions. What are some of the possible solutions
in the 200 vs 3 nodes case? A collection of node objects? One thread or many?
I'm not sure. Advise me.
2. I reject all the ones that couldn't possibly work. Are there any node
solutions that couldn't possibly work? Please discuss.
3. I pick what appears to me to be the simplest remaining solution (i.e. one
that could work) and I implement it.
4. In the course of implementation, I follow all the other rules that go with
XP's notion of simplicity. In particular, I support everything with
comprehensive tests, and I refactor until Beck's rules of simple code are met.
('ll list those below.)
When I do those four things, here's what happens:
* I never try anything that I'm sure won't work. Therefore, if my fear is high
about some solution scaling, I won't try it because I think it couldn't possibly
work.
* What I wind up with at the end of the cycle is highly modular code. Each
object in its place, each method simple, and so on.
The result is that when new requirements for function or performance come along,
the overall shape of the objects is there, visible, and good. The changes for
the next requirement tend to go right in.
That's what happens to me. I'd like to know what you think you would do in the
200 vs 3 node case that is likely different from what I'd do, so that we can
consider how much trouble I might get into.
Thanks!
Now here are Beck's rules for Simple Code. Simple Code meets these four
criteria, in priority order:
1. Simple code runs all the tests correctly;
2. Simple code contains no duplication;
3. Simple code expresses every idea the programmer had during implementation;
4. Simple code minimizes the number of classes and methods used.
That's what I mean by "Do the simplest thing that could possibly work". Pick an
idea that I feel could work. Implement it in Simple Code. Let's talk about the
200 vs 3 node case now?
Ron Jeffries
>Yep. If we could just get you and a few others to stop turning technical
>discussions into your own personal platforms for launching personal
>attacks, this ng would be a lot more interesting.
I'll take that as a challenge, and having found the reasonable and fair
questions below, I'll discuss them technically. We'll see what happens.
On Sun, 16 Feb 2003 16:35:51 GMT, "Shayne Wissler" <thal...@yahoo.com> wrote:
>
>"Ron Jeffries" <ronje...@REMOVEacm.org> wrote in message
>news:s5ou4v4f3lsf06cc3...@4ax.com...
>
>> First of all, we are speculating about the problem. We are speculating --
>though
>> we can be pretty sure -- that we'll need to support Contractors. We have
>no such
>> need now.
>
>When you say that, do you mean that you're not aware of the requirement, or
>only that it's not on today's cards?
We're talking about Contractors. We know there will be the requirement. It's not
on today's cards.
>Or, do you think these are one in the
>same? In your world, is any thought past today's cards "speculation"?
No. We are free to think about anything we want to. We recommend implementing
the code for today's requirements only.
>
>Certainly the situation could happen where the customer says "I absolutely
>want Contractors support, but we'll add that feature next week. Today we're
>just working on SalariedEmployee."
Yes. I believe in this discussion we are assuming that the Contractor
requirement really will come along. We are not saying "well, it might not".
We're saying something much more controversial: "Even knowing that Contractor
will come along next week, we would implement no hooks for it this week."
Discussion?
Tim Ottinger
> 1. Simple code runs all the tests correctly;
> 2. Simple code contains no duplication;
> 3. Simple code expresses every idea the programmer had during implementation;
"had" or "kept"?
Paul Campbell
"Ron Jeffries" <ronje...@REMOVEacm.org> wrote in message news:3q445vkcefegeuqv6...@4ax.com...
> On Tue, 18 Feb 2003 08:58:44 -0000, "Paul Campbell"
> <p.au.l.ca...@ob.jectvi.sion.c.o.u.k> wrote:
> That's what happens to me. I'd like to know what you think you would do in the
> 200 vs 3 node case that is likely different from what I'd do, so that we can
> consider how much trouble I might get into.
The primary consideration is that it takes us over the boundary of what can work
with a single process on a single machine. Infact the number 200 is only illustrative
as the real requirement is to manage an "entire access network" which tend to
get quite large. If I am to attain my goal of designing a near-zero manual administration
and yet "infinately" scalable network management system I need to sew the seeds
well ahead of time. With this sort of system the actual business logic is less of a
problem than issues of sycronisation of various data stores and caches and other
complexities inherent in highly distributes systems.
Its also worth noting that a system which provided 1:1 managment via a Local Craft
Terminal (LCT) (which was infact network capable and therefore not really "local")
already existed, and thus requierment for the "proper" management system was
a unified and intergrated yet scalable system. Thus it could be argued that the STTW
already existed.
A points of context: I am not a proponent of waterfall-like Big Upfront Design,
indeed I would say that in general too much is done up front rather than too
little so I am sympathetic to attemps to move in the other direction - just not to
to eliminate any future proofing completely.
Paul C.
Otis Bricker
> "Shayne Wissler" <thal...@yahoo.com> wrote in
> news:dh84a.139059$iG3.17133@sccrnsc02:
>
> Well there goes another good thread down the toilette.
It is easier if you just filter trolls from the start. That way you
are not tempted to respond. If someone else answers, you can respond
to them to correct any misunderstanding. And if no one at all responds
to a troll, so much the better. So add folks to your filter as soon as
you realise that they repeat the same trollish behavior.
Its up to you to decide who the trolls are. Different people see
things differently.
Otis
Jim Sontag
> In article <3E51101F...@jim.sontag>,
> Jim Sontag <ca....@jim.sontag> wrote:
> [...]
>
>>>An example in C++ would be making an abstract base class and overriding
>>>it with 1 sub-class to make it easier to add new sub-classes in the
>>>future. The hooks are the virtual function declarations and the base
>>>class is not needed yet.
>>>
>>
>>IMHO, this would certainly qualify as gold plating. I also
>>find it plausible that a customer (or master) might ask for
>>this.
>
> [...]
>
[...]
>
> My point is that on a large project, making an abstract base class and
> overriding it with one sub-class might practiced as part of the
> necessity of keeping compilation times down, and therefore not be
> gold-plating.
OK Kieth, we'll do it then, it sounds like you have good
reasons. You're the customer.
If faced with a similar question in the future however, I'm
still going to fall back on the YAGNI rule of thumb.
Jim
Keith Ray
Jim Sontag <ca....@jim.sontag> wrote:
> > My point is that on a large project, making an abstract base class and
> > overriding it with one sub-class might practiced as part of the
> > necessity of keeping compilation times down, and therefore not be
> > gold-plating.
>
>
> OK Keith, we'll do it then, it sounds like you have good
> reasons. You're the customer.
>
> If faced with a similar question in the future however, I'm
> still going to fall back on the YAGNI rule of thumb.
No I'm not the customer. I'm the programmer following Beck's suggestion
that we have quick turn-around in compilation and testing (required for
TDD and XP). There's no YAGNI at all -- we have to do this NOW to keep
the program compiling quickly. We are not predicting future requirements
and implementing unnecessary hooks (we are merely compensating for C++'s
lack of true encapsulation.)
Shayne Wissler
"Ron Jeffries" <ronje...@REMOVEacm.org> wrote in message
> >"Ron Jeffries" <ronje...@REMOVEacm.org> wrote in message
> >news:s5ou4v4f3lsf06cc3...@4ax.com...
> >
> >> First of all, we are speculating about the problem. We are
speculating --
> >though
> >> we can be pretty sure -- that we'll need to support Contractors. We
have
> >no such
> >> need now.
> >
> >When you say that, do you mean that you're not aware of the requirement,
or
> >only that it's not on today's cards?
>
> We're talking about Contractors. We know there will be the requirement.
It's not
> on today's cards.
The situation I'm interested in is the one where Contractors is an absolute
requirement--where it must be implemented before the system can go online.
> >Or, do you think these are one in the
> >same? In your world, is any thought past today's cards "speculation"?
>
> No. We are free to think about anything we want to. We recommend
implementing
> the code for today's requirements only.
I'm fine with that statement by itself--it's just a statement of iterative
development. We can only do one thing at a time. The issue is: how do you
pick the order of implementation? Perhaps it would be technically better to
omit some of the details on SalariedEmployee, and implement part of
Contractor, just to ensure that the architecture is robust. XP doesn't allow
this refinement of the implementation ordering, because it doesn't allow the
evaluation to take place: only the customer determines what will be
implemented when.
I posted on this issue yesterday in reply to one of Bob's posts.
> >Certainly the situation could happen where the customer says "I
absolutely
> >want Contractors support, but we'll add that feature next week. Today
we're
> >just working on SalariedEmployee."
>
> Yes. I believe in this discussion we are assuming that the Contractor
> requirement really will come along. We are not saying "well, it might
not".
> We're saying something much more controversial: "Even knowing that
Contractor
> will come along next week, we would implement no hooks for it this week."
I'll just restate my point: Maybe it would be better to implement part of
SalariedEmployee, and part of Contractor, to insure that the architecture is
robust. In general, it's easier to add details to a class than to shift
things around to make room for a new one. Refactoring is good, but avoiding
the need for it when you can is even better.
Shayne Wissler
Ron Jeffries
Without going back to the source, I think he said "had". Doubtless he meant
"kept" and "about the program". Ideas about where to have lunch do not need to
be recorded in the code. ;->
Ron Jeffries
>> We're talking about Contractors. We know there will be the requirement.
>It's not
>> on today's cards.
>
>The situation I'm interested in is the one where Contractors is an absolute
>requirement--where it must be implemented before the system can go online.
Yes. I understand that it absolutely will be implemented before we go on line.
If the story for Contractors is not in this iteration I would not implement a
line of code for it in this iteration. I would not create the abstract
superclass or a test for isContractor or anything else, until I had an actual
scheduled requirement that called for it.
>
>> >Or, do you think these are one in the
>> >same? In your world, is any thought past today's cards "speculation"?
>>
>> No. We are free to think about anything we want to. We recommend
>implementing
>> the code for today's requirements only.
>
>I'm fine with that statement by itself--it's just a statement of iterative
>development. We can only do one thing at a time. The issue is: how do you
>pick the order of implementation? Perhaps it would be technically better to
>omit some of the details on SalariedEmployee, and implement part of
>Contractor, just to ensure that the architecture is robust.
Perhaps it would. If the customer wants SE first and then Contractor, I'm
generally OK with that. If there are issues of risk or serious cost differences
in the order, it would show up in the planning process.
For example. Suppose that doing SE first would cost 5, and then doing Contractor
would cost 10. But that doing Contractor first would cost 6 and then SE would
cost 6. When the stories are estimated, the programmers would make exactly those
estimates and let the customer decide.
It is the customer's job to decide business value. I would expect that if she
were indifferent to the order of delivery, she would pick the cheaper sequence.
If she had some reason to need SE first, such as a show or a demonstration or
something, she might prefer to pay the higher price to get it first.
>XP doesn't allow
>this refinement of the implementation ordering, because it doesn't allow the
>evaluation to take place: only the customer determines what will be
>implemented when.
The above sentence is incorrect. Because the stories are estimated as to their
relative cost, if there are differences in the sequence, it will be made clear
and the customer can decide based on the estimated costs, as per my example just
above. For more info on this read the chapters on the Planning Game in the
various books, or the entire Planning Extreme Programming book. But I would hope
that the general principle is clear: since the stories are estimated by the
programmers, any cost impact from the order of implementation is made publicly
available so that a suitable business decision can be made.
>
>I posted on this issue yesterday in reply to one of Bob's posts.
>
>> >Certainly the situation could happen where the customer says "I
>absolutely
>> >want Contractors support, but we'll add that feature next week. Today
>we're
>> >just working on SalariedEmployee."
>>
>> Yes. I believe in this discussion we are assuming that the Contractor
>> requirement really will come along. We are not saying "well, it might
>not".
>> We're saying something much more controversial: "Even knowing that
>Contractor
>> will come along next week, we would implement no hooks for it this week."
>
>I'll just restate my point: Maybe it would be better to implement part of
>SalariedEmployee, and part of Contractor, to insure that the architecture is
>robust. In general, it's easier to add details to a class than to shift
>things around to make room for a new one. Refactoring is good, but avoiding
>the need for it when you can is even better.
Maybe it would be better in some sense. What more information would be needed
besides the relative costs of both ways, which the programmers produce as part
of the planning game, and the understanding of the relative business value of
the two ways, which the customer brings to the planning game?
Regards,
Ron Jeffries
wrote:
>> > My point is that on a large project, making an abstract base class and
>> > overriding it with one sub-class might practiced as part of the
>> > necessity of keeping compilation times down, and therefore not be
>> > gold-plating.
>>
>>
>> OK Keith, we'll do it then, it sounds like you have good
>> reasons. You're the customer.
>>
>> If faced with a similar question in the future however, I'm
>> still going to fall back on the YAGNI rule of thumb.
>
>No I'm not the customer. I'm the programmer following Beck's suggestion
>that we have quick turn-around in compilation and testing (required for
>TDD and XP). There's no YAGNI at all -- we have to do this NOW to keep
>the program compiling quickly. We are not predicting future requirements
>and implementing unnecessary hooks (we are merely compensating for C++'s
>lack of true encapsulation.)
I would certainly agree that the programmers might do something to keep compile
and test time low. I don't see how a program with an abstract base class plus a
concrete subclass could possible compile faster than one with just the concrete
class. But if that were to happen, and the difference were significant, then
certainly the programmers might choose to do it.
As for any performance optimization, I'd want to see the test that shows that
the optimization is necessary, and the test that shows the benefit derived.
Jeremy Dunck
<ronje...@REMOVEacm.org> wrote:
>On Tue, 18 Feb 2003 13:24:06 GMT, Tim Ottinger <tott...@indy.rr.com> wrote:
>
>>Ron Jeffries wrote:
>>> 1. Simple code runs all the tests correctly;
>>> 2. Simple code contains no duplication;
>>> 3. Simple code expresses every idea the programmer had during implementation;
>>
>>"had" or "kept"?
>>
>>
>>> 4. Simple code minimizes the number of classes and methods used.
>
>Without going back to the source, I think he said "had". Doubtless he meant
>"kept" and "about the program". Ideas about where to have lunch do not need to
>be recorded in the code. ;->
Actually, this brings up an interesting point... The need for comments
are often cited as a code smell, yet I think a comment about why an
alternative approach was -not- taken is a useful thing.
//Don't use a linked list here, because it'll be searched a lot,
//and BST is much faster.
...and so on.
Obviously, you don't need to document every little thing that
-doesn't- sound good, but just as FAQs are useful at addressing
frequent questions (and allowing greater productivity), I imagine some
comments about common poor approaches might save redundant thought on
the issue.
Shayne Wissler
> On Tue, 18 Feb 2003 16:55:14 GMT, "Shayne Wissler" <thal...@yahoo.com>
> wrote:
>
>>> We're talking about Contractors. We know there will be the requirement.
>>It's not
>>> on today's cards.
>>
>>The situation I'm interested in is the one where Contractors is an
>>absolute requirement--where it must be implemented before the system can
>>go online.
>
> Yes. I understand that it absolutely will be implemented before we go on
> line. If the story for Contractors is not in this iteration I would not
> implement a line of code for it in this iteration. I would not create the
> abstract superclass or a test for isContractor or anything else, until I
> had an actual scheduled requirement that called for it.
This leaves me wondering if we mean the same thing by "online". By "online",
I mean the system is actually generating business value, not merely that
the customer has a working system in his hands, one that isn't
full-featured enough for him to do anything with that actually leads to
increased profits.
I'm talking about an objectively deployed system here, not merely one that
you happened to throw over the wall as a step in iterative testing. I don't
care if the customer's playing with it--it's not deployed until it's
working in the context of the customer's ultimate goal.
>>> >Or, do you think these are one in the
>>> >same? In your world, is any thought past today's cards "speculation"?
>>>
>>> No. We are free to think about anything we want to. We recommend
>>implementing
>>> the code for today's requirements only.
>>
>>I'm fine with that statement by itself--it's just a statement of iterative
>>development. We can only do one thing at a time. The issue is: how do you
>>pick the order of implementation? Perhaps it would be technically better
>>to omit some of the details on SalariedEmployee, and implement part of
>>Contractor, just to ensure that the architecture is robust.
>
> Perhaps it would. If the customer wants SE first and then Contractor, I'm
> generally OK with that. If there are issues of risk or serious cost
> differences in the order, it would show up in the planning process.
>
> For example. Suppose that doing SE first would cost 5, and then doing
> Contractor would cost 10. But that doing Contractor first would cost 6 and
> then SE would cost 6. When the stories are estimated, the programmers
> would make exactly those estimates and let the customer decide.
How could you make this calcuation in XP? It's hardly self-evident. In order
to do it you need to know:
- the requirements for the system as a whole--not just those for next week
- an analysis of these requirements as a whole
- the ultimate architecture that will be deployed (if you don't know the
final form of the system in some terms, you can't possibly make
calculations regarding the most efficient way of getting into that final
form).
All of this is anathema to XP, but is precisely what is required in order to
make assessments of the kind I'm talking about.
> It is the customer's job to decide business value.
Yes and no. Yes to your literal statement. No to what you mean by it. The
literal statement, taken objectively, means: the customer should specify
what value he intends to get out of the system, at what points in time, and
he should tie it in some way to expected profits.
What you mean by it is that the customer should decide on a weekly basis
what items to implement. In some cases this does relate to business value,
but in general, for long-running projects, a weekly list is meaningless in
the context of actual business value. The fact is that for anything but
trivial projects, you need a month or more of implementation in order to
get to a system that provides any actual business value at all.
So when you say "business value", you mean "customer whims and guesses." You
don't mean business value. And you're not going to provide the customer
with any objective means of providing you with an objective order of
implementation, because you refuse to look at the requirements as a whole
and identify an architecture. I.e., it's not the customer's fault that all
he has is whims and guesses, it's yours. You're removed any means of
objectivity from the process when you removed up-front analysis and
architecture.
Now I am not saying use BUFD. The means by which I "compute" the
architecture is, in part, to implement it. But I prioritze development
around identifying the architecture--that is the first phase of any project
I work on. The thing driving the implementation at this point is
architectural risk--I try to identify any and all requirements that could
break my idea of how the system should work, and implement those. Once the
architecture is proven, then I proceed to a mode of development that isn't
all that different from XP (leaving aside the egalitarianism).
> I would expect that if
> she were indifferent to the order of delivery, she would pick the cheaper
> sequence. If she had some reason to need SE first, such as a show or a
> demonstration or something, she might prefer to pay the higher price to
> get it first.
Ideally, you finish the architecture phase of the project, and then you
crank out features in customer-desired order.
>>XP doesn't allow
>>this refinement of the implementation ordering, because it doesn't allow
>>the evaluation to take place: only the customer determines what will be
>>implemented when.
>
> The above sentence is incorrect. Because the stories are estimated as to
> their relative cost, if there are differences in the sequence, it will be
> made clear and the customer can decide based on the estimated costs, as
> per my example just above. For more info on this read the chapters on the
> Planning Game in the various books, or the entire Planning Extreme
> Programming book. But I would hope that the general principle is clear:
> since the stories are estimated by the programmers, any cost impact from
> the order of implementation is made publicly available so that a suitable
> business decision can be made.
How can you possibly estimate anything without knowing what you're building?
>>I posted on this issue yesterday in reply to one of Bob's posts.
>>
>>> >Certainly the situation could happen where the customer says "I
>>absolutely
>>> >want Contractors support, but we'll add that feature next week. Today
>>we're
>>> >just working on SalariedEmployee."
>>>
>>> Yes. I believe in this discussion we are assuming that the Contractor
>>> requirement really will come along. We are not saying "well, it might
>>not".
>>> We're saying something much more controversial: "Even knowing that
>>Contractor
>>> will come along next week, we would implement no hooks for it this
>>> week."
>>
>>I'll just restate my point: Maybe it would be better to implement part of
>>SalariedEmployee, and part of Contractor, to insure that the architecture
>>is robust. In general, it's easier to add details to a class than to shift
>>things around to make room for a new one. Refactoring is good, but
>>avoiding the need for it when you can is even better.
>
> Maybe it would be better in some sense. What more information would be
> needed besides the relative costs of both ways, which the programmers
> produce as part of the planning game, and the understanding of the
> relative business value of the two ways, which the customer brings to the
> planning game?
It's not that more information is needed, it's that you have to have a means
of getting that information. You don't just divine it out of thin air.
Shayne Wissler
Ron Jeffries
>Ron Jeffries wrote:
>
>> On Tue, 18 Feb 2003 16:55:14 GMT, "Shayne Wissler" <thal...@yahoo.com>
>> wrote:
>>
>>>> We're talking about Contractors. We know there will be the requirement.
>>>It's not
>>>> on today's cards.
>>>
>>>The situation I'm interested in is the one where Contractors is an
>>>absolute requirement--where it must be implemented before the system can
>>>go online.
>>
>> Yes. I understand that it absolutely will be implemented before we go on
>> line. If the story for Contractors is not in this iteration I would not
>> implement a line of code for it in this iteration. I would not create the
>> abstract superclass or a test for isContractor or anything else, until I
>> had an actual scheduled requirement that called for it.
>
>This leaves me wondering if we mean the same thing by "online". By "online",
>I mean the system is actually generating business value, not merely that
>the customer has a working system in his hands, one that isn't
>full-featured enough for him to do anything with that actually leads to
>increased profits.
I believe we are talking about a situation where the system cannot be fully
acceptable unless Contractor is in it. And, because we're talking about
refactoring, incremental development, and XP, we are talking about an increment
(iteration) in which the customer has not yet asked for any Contractor
functionality.
The question was, I believe: would you put in any special hooks to provide for
Customer later, such as an abstract superclass.
My answer is: No, I would not put in an abstract superclass unless I had some
reason in the current version. I would put it in when the code really needs it.
I would not put it in "in anticipation" of that need.
>
>I'm talking about an objectively deployed system here, not merely one that
>you happened to throw over the wall as a step in iterative testing. I don't
>care if the customer's playing with it--it's not deployed until it's
>working in the context of the customer's ultimate goal.
XP teams do not "throw over the wall". And we DO care if the customer is playing
with it. I agree that it might not be fully deployed.
>
>>>> >Or, do you think these are one in the
>>>> >same? In your world, is any thought past today's cards "speculation"?
>>>>
>>>> No. We are free to think about anything we want to. We recommend
>>>implementing
>>>> the code for today's requirements only.
>>>
>>>I'm fine with that statement by itself--it's just a statement of iterative
>>>development. We can only do one thing at a time. The issue is: how do you
>>>pick the order of implementation? Perhaps it would be technically better
>>>to omit some of the details on SalariedEmployee, and implement part of
>>>Contractor, just to ensure that the architecture is robust.
>>
>> Perhaps it would. If the customer wants SE first and then Contractor, I'm
>> generally OK with that. If there are issues of risk or serious cost
>> differences in the order, it would show up in the planning process.
>>
>> For example. Suppose that doing SE first would cost 5, and then doing
>> Contractor would cost 10. But that doing Contractor first would cost 6 and
>> then SE would cost 6. When the stories are estimated, the programmers
>> would make exactly those estimates and let the customer decide.
>
>How could you make this calcuation in XP? It's hardly self-evident.
XP is not "self-evident". To understand it it is helpful to read the material
about it, and to practice the techniques. If you encounter questions in that
process, we are here to help.
>In order
>to do it you need to know:
> - the requirements for the system as a whole--not just those for next week
Yes, the more requirements you know, the better. The XP "Release Plan" provides
estimates for all known requirements. This is done at the beginning of the
project and many times throughout. This process element is explained in great
detail in the book "Planning Extreme Programming", in a fair amount of detail in
"Extreme Programming Installed", and in the other books as well. I commend study
of "Release Plan" to your attention.
> - an analysis of these requirements as a whole
Yes. See above.
> - the ultimate architecture that will be deployed (if you don't know the
>final form of the system in some terms, you can't possibly make
>calculations regarding the most efficient way of getting into that final
>form).
I would imagine that no one knows the ultimate architecture that will be
deployed. It turns out that nonetheless, people have been estimating projects
for years.
The XP style of estimation is to break the features down into very small pieces.
We call them stories. Then we estimate them all. I can teach an XP-sized team
how to get estimates they consider to be good enough to work with, in just a few
days.
>
>All of this is anathema to XP, but is precisely what is required in order to
>make assessments of the kind I'm talking about.
None of it is anathema to XP. You keep saying things about XP that are simply
not true. That doesn't help us progress, in my opinion.
>
>> It is the customer's job to decide business value.
>
>Yes and no. Yes to your literal statement. No to what you mean by it. The
>literal statement, taken objectively, means: the customer should specify
>what value he intends to get out of the system, at what points in time, and
>he should tie it in some way to expected profits.
>
>What you mean by it is that the customer should decide on a weekly basis
>what items to implement. In some cases this does relate to business value,
>but in general, for long-running projects, a weekly list is meaningless in
>the context of actual business value. The fact is that for anything but
>trivial projects, you need a month or more of implementation in order to
>get to a system that provides any actual business value at all.
>
>So when you say "business value", you mean "customer whims and guesses." You
>don't mean business value. And you're not going to provide the customer
>with any objective means of providing you with an objective order of
>implementation, because you refuse to look at the requirements as a whole
>and identify an architecture. I.e., it's not the customer's fault that all
>he has is whims and guesses, it's yours. You're removed any means of
>objectivity from the process when you removed up-front analysis and
>architecture.
I understand all of the above to be your opinion about what you know how to do.
What XP teams all over the world are doing is delivering software every two
weeks, in which the customer can see elements of business value. They do this in
a way that provides an ever-improving estimate of the difficulty of future
features, an ever-improving suite of tests, and a continually-increasing
assessment of business value by the customer.
It does not help to say that we cannot do this. We are doing it.
>
>Now I am not saying use BUFD. The means by which I "compute" the
>architecture is, in part, to implement it. But I prioritze development
>around identifying the architecture--that is the first phase of any project
>I work on. The thing driving the implementation at this point is
>architectural risk--I try to identify any and all requirements that could
>break my idea of how the system should work, and implement those. Once the
>architecture is proven, then I proceed to a mode of development that isn't
>all that different from XP (leaving aside the egalitarianism).
An XP team proves its architecture every two weeks, by shipping running, tested
software with more and more architecture worked into it. It's a different way
from what you seem to be describing, but it is a way that people do, and that
works for them.
I don't understand what you are saying about egalitarianism, but I am guess you
mean that you are against it. That's OK with me.
>
>> I would expect that if
>> she were indifferent to the order of delivery, she would pick the cheaper
>> sequence. If she had some reason to need SE first, such as a show or a
>> demonstration or something, she might prefer to pay the higher price to
>> get it first.
>
>Ideally, you finish the architecture phase of the project, and then you
>crank out features in customer-desired order.
That is a way that some teams build software. I guess you mean that it is your
preferred way. It is not what XP recommends, and it is not what XP teams are
actually doing.
>>>XP doesn't allow
>>>this refinement of the implementation ordering, because it doesn't allow
>>>the evaluation to take place: only the customer determines what will be
>>>implemented when.
>>
>> The above sentence is incorrect. Because the stories are estimated as to
>> their relative cost, if there are differences in the sequence, it will be
>> made clear and the customer can decide based on the estimated costs, as
>> per my example just above. For more info on this read the chapters on the
>> Planning Game in the various books, or the entire Planning Extreme
>> Programming book. But I would hope that the general principle is clear:
>> since the stories are estimated by the programmers, any cost impact from
>> the order of implementation is made publicly available so that a suitable
>> business decision can be made.
>
>How can you possibly estimate anything without knowing what you're building?
It's easy. Get the list of features. If a feature is too big to estimate, break
it down into smaller subfeatures. When they are all small enough, estimate them
and add them up. I have a one-day course in how to do this. Real teams learn to
do it with their own requirements in a few days.
Naturally, the early estimates are less accurate than later ones. Yet they work
quite well enough to get started. After only a couple of iterations' work, the
team has a good -- and improving -- sense of how fast they can go and how good
their estimates are.
No one said that you should divine it out on thin air. May I respectfully
suggest that you study a bit on what we do suggest? The ideas above in this note
just scratch the surface of what XP teaches. You'll be able to ask better
questions and make better ciriticisms the more you know about it.
David B Lightstone
"Jeremy Dunck" <jeremy.remove....@dunck.us> wrote in message
news:FA6FF1F884352807.69D3C8C1...@lp.airnews.net...
> On Tue, 18 Feb 2003 14:36:57 -0500, Ron Jeffries
> <ronje...@REMOVEacm.org> wrote:
>
> >On Tue, 18 Feb 2003 13:24:06 GMT, Tim Ottinger <tott...@indy.rr.com>
wrote:
> >
> >>Ron Jeffries wrote:
> >>> 1. Simple code runs all the tests correctly;
> >>> 2. Simple code contains no duplication;
> >>> 3. Simple code expresses every idea the programmer had during
implementation;
> >>
> >>"had" or "kept"?
> >>
> >>
> >>> 4. Simple code minimizes the number of classes and methods used.
> >
> >Without going back to the source, I think he said "had". Doubtless he
meant
> >"kept" and "about the program". Ideas about where to have lunch do not
need to
> >be recorded in the code. ;->
>
> Actually, this brings up an interesting point... The need for comments
> are often cited as a code smell, yet I think a comment about why an
> alternative approach was -not- taken is a useful thing.
Inappropriate for the code, but definitely documentation in need of being
produced. Won't happen on an XP project, however. That is probably
mishandled by the pair or in the group bull session
Jeremy Dunck
<david.lightst...@prodigy.net> wrote:
>
>"Jeremy Dunck" <jeremy.remove....@dunck.us> wrote in message
<snip>
>> >>> 4. Simple code minimizes the number of classes and methods used.
>> >
>> >Without going back to the source, I think he said "had". Doubtless he
>meant
>> >"kept" and "about the program". Ideas about where to have lunch do not
>need to
>> >be recorded in the code. ;->
>>
>> Actually, this brings up an interesting point... The need for comments
>> are often cited as a code smell, yet I think a comment about why an
>> alternative approach was -not- taken is a useful thing.
>
>Inappropriate for the code, but definitely documentation in need of being
>produced. Won't happen on an XP project, however. That is probably
>mishandled by the pair or in the group bull session
>
<snip>
Actually, in my experience, technical specs done before coding rarely
fortell such implementation issues, and tech specs done in hindsight
are usually English-ified code, which noone but the coders can
understand, nor cares to.
As I understand XP, such knowledge is not isolated to a single coder,
due to the collective ownership.
It is possible that I've never had the good fortune to work with a
business analyst or architect worth his pay, and that my experience is
skewed.
Anyway, I believe that documenting the rationale behind design and
code decisions is much more valuable than documenting exactly how the
code what it does. The code is expressive to anyone that cares to
hear that level of detail, IMHO.
Does your experience differ?
Paul Sinnett
>> To me, it means "do the *right* thing and do it as simply as
>> possible." The former part of that is a fundamental to any
>> methodology (and something XP takes for granted, btw). The latter
>> part is the really neat idea, and its effect on one's code is the
>> really interesting thing worth investigating for oneself.
>
> We probably need an alternative to FAQ, maybe MFM? for Most Frequent
> Misinterpretation.
>
> People confuse "simple" with "easy" or "quick". I don't see anyplace
> where XP says to take the shortest shortcut to getting the code
> written, but it definitely says to keep the current design the
> /simplest/ it can be, where /simple/ is a quality of the design, no a
> measurement of the programmer's time or effort.
I don't see how this is a misinterpretation. The last draft of TDD by
example (Kent Beck) that I read, stated this explicitly:
> The two rules imply an order to the tasks of programming:
>
> o Red—write a little test that doesn’t work, perhaps doesn’t even
> compile at first
> o Green—make the test work quickly, committing whatever sins
> necessary in the process
> o Refactor—eliminate all the duplication created in just getting
> the test to work
>
> Red/green/refactor. The TDDs mantra.
Keith Ray
Ron Jeffries <ronje...@REMOVEacm.org> wrote:
> On Tue, 18 Feb 2003 16:50:32 GMT, Keith Ray <k1e2i3t...@1m2a3c4.5c6o7m>
> wrote:
[...]
> I would certainly agree that the programmers might do something to keep
> compile
> and test time low. I don't see how a program with an abstract base class plus
> a
> concrete subclass could possible compile faster than one with just the
> concrete
> class. But if that were to happen, and the difference were significant, then
> certainly the programmers might choose to do it.
>
> As for any performance optimization, I'd want to see the test that shows that
> the optimization is necessary, and the test that shows the benefit derived.
Here are my results:
I did this kind of thing to around 10 most "popular" classes out of 100+
classes on the project I'm currently working on, compile time went down
from 20 minutes to 17 minutes.
I did the pImpl idiom to slightly more than a dozen classes out of 200+
classes, on a previous project, and compile time went down from 11
minutes to 7 minutes.
It all has to do with how many times the compiler has to parse a header
file. If a header file is included by 50 classes, it gets parsed 50
times and every header file it *includes* also gets parsed about 50
times. That adds up, even though we use "pragma once" in each header.
Dual processor pentium-whatevers, WinNT box, VC++ 6.0, 800 MHz.
These are complete re-builds that we do after a check-out, because
sometimes the compiler doesn't recompile the proper files.
You don't have this problem in Java, because the compiler, when it is
compiling a .java file, looks at the compiled .class files for the other
classes -- it doesn't look at other .java files when it is compiling a
.java file.
Java build times are linear, while C++ compile times are exponential.
Jeremy Dunck
<k1e2i3t...@1m2a3c4.5c6o7m> wrote:
>In article <ha355vctd9mg2p30p...@4ax.com>,
> Ron Jeffries <ronje...@REMOVEacm.org> wrote:
>
>> On Tue, 18 Feb 2003 16:50:32 GMT, Keith Ray <k1e2i3t...@1m2a3c4.5c6o7m>
>> wrote:
>[...]
<snip>
>It all has to do with how many times the compiler has to parse a header
>file. If a header file is included by 50 classes, it gets parsed 50
>times and every header file it *includes* also gets parsed about 50
>times. That adds up, even though we use "pragma once" in each header.
>
>Dual processor pentium-whatevers, WinNT box, VC++ 6.0, 800 MHz.
>
>These are complete re-builds that we do after a check-out, because
>sometimes the compiler doesn't recompile the proper files.
>
>You don't have this problem in Java, because the compiler, when it is
>compiling a .java file, looks at the compiled .class files for the other
>classes -- it doesn't look at other .java files when it is compiling a
>.java file.
>
>Java build times are linear, while C++ compile times are exponential.
Huh.
Unless I'm missing something (Can the header files change between
includes?), it seems like this is just a poorly optimized compiler.
Having parsed an include, couldn't the compiler cache that result in
case other modules include it? Or is this a complexity introduced by
macros and precompiler switches?
Keith Ray
<05EC6AB3AEE5D194.24C839C9...@lp.airnews.net>,
Jeremy Dunck <jeremy.remove....@dunck.us> wrote:
[...]
> Unless I'm missing something (Can the header files change between
> includes?), it seems like this is just a poorly optimized compiler.
>
> Having parsed an include, couldn't the compiler cache that result in
> case other modules include it? Or is this a complexity introduced by
> macros and precompiler switches?
This is what the compiler has to do because the language has those evil
macros in it.
Here's a terrible example (which won't work if you're using #pragma once)
#define CString YuckyString
#include "CString.h"
#undef CString
#define CString BlechString
#include "CString.h"
#undef CString
void Blargh( YuckyString y, BlechString z )
{
....
Shayne Wissler
> That is a way that some teams build software. I guess you mean that it is
> your preferred way. It is not what XP recommends, and it is not what XP
> teams are actually doing.
Ron, the whole point of my post was precisely to indicate some of the
reasons why an architecture-driven approach is better than the XP approach.
If you don't want to have a discussion about the reasons why, then just say
so.
But I'm not interested in a mere re-iteration of what we both know about XP,
so if you're not interested in evaluating XP relative to other approaches,
then we have nothing to talk about.
Shayne Wissler
Otis Bricker
> On Tue, 18 Feb 2003 13:24:06 GMT, Tim Ottinger <tott...@indy.rr.com>
> wrote:
>
>>Ron Jeffries wrote:
>>> 1. Simple code runs all the tests correctly;
>>> 2. Simple code contains no duplication;
>>> 3. Simple code expresses every idea the programmer had during
>>> implementation;
>>
>>"had" or "kept"?
>>
>>
>>> 4. Simple code minimizes the number of classes and methods used.
>
> Without going back to the source, I think he said "had". Doubtless he
> meant "kept" and "about the program". Ideas about where to have lunch
> do not need to be recorded in the code. ;->
>
I'm not sure what your source was. It is likely more direct than mine which
is XPE. There he says the constraints, again in priority order, are:
1. The system ( code and tests) must communicate everything you want to
communicate.
2. The system must contain no duplicate code( 1 and 2 together constitute
the Once and Once Only rule)
3. The system should have the fewest possible classes.
4. The system should have the fewest possible methods.
I imagine that your number one was obviously implied and that 3 and 4 were
combined to keep things at 4.
Otis B.
Kevin Cline
> I would certainly agree that the programmers might do something to keep compile
> and test time low. I don't see how a program with an abstract base class plus a
> concrete subclass could possible compile faster than one with just the concrete
> class. But if that were to happen, and the difference were significant, then
> certainly the programmers might choose to do it.
Introducing an abstract base class won't help the initial compilation,
but may help the total compilation time during development by reducing
the amount of code that must be recompiled when the concrete class
implementation changes. This can be a big savings if the interface
is stable but the implementation is under development.
Ron Jeffries
wrote:
>
>I'm not sure what your source was. It is likely more direct than mine which
>is XPE. There he says the constraints, again in priority order, are:
>
>1. The system ( code and tests) must communicate everything you want to
>communicate.
>
>2. The system must contain no duplicate code( 1 and 2 together constitute
>the Once and Once Only rule)
>
>3. The system should have the fewest possible classes.
>
>4. The system should have the fewest possible methods.
>
>
>I imagine that your number one was obviously implied and that 3 and 4 were
>combined to keep things at 4.
That's the version on page 109. There's one on page 57 that is closer to the way
I put it.
Ron Jeffries
>> That is a way that some teams build software. I guess you mean that it is
>> your preferred way. It is not what XP recommends, and it is not what XP
>> teams are actually doing.
>
>Ron, the whole point of my post was precisely to indicate some of the
>reasons why an architecture-driven approach is better than the XP approach.
>If you don't want to have a discussion about the reasons why, then just say
>so.
>
>But I'm not interested in a mere re-iteration of what we both know about XP,
>so if you're not interested in evaluating XP relative to other approaches,
>then we have nothing to talk about.
Do you see that YOU have just changed the subject from XP and alternatives, to
me as person?
Return to the topic, or not. I don't care.
Shayne Wissler
> On Tue, 18 Feb 2003 23:27:59 GMT, Shayne Wissler <thal...@yahoo.com>
> wrote:
>
>>> That is a way that some teams build software. I guess you mean that it
>>> is your preferred way. It is not what PX recommends, and it is not what
>>> PX teams are actually doing.
>>
>>Ron, the whole point of my post was precisely to indicate some of the
>>reasons why an architecture-driven approach is better than the PX
>>approach. If you don't want to have a discussion about the reasons why,
>>then just say so.
>>
>>But I'm not interested in a mere re-iteration of what we both know about
>>PX, so if you're not interested in evaluating PX relative to other
>>approaches, then we have nothing to talk about.
>
> Do you see that YOU have just changed the subject from PX and
> alternatives, to me as person?
No. The subject is not "Ron is a troll"--or any other kind of character
assassination (as you and a few others have indulged in). The subject is
"What does Ron care to talk about?" If we don't have common interests here
then what's the point?
> Return to the topic, or not. I don't care.
Let me guess: you were trolling me, but I'm not cooperating so now you're
giving up. You wanted me to insult you in some way so you could throw my
comment back in my face, and my above statement was the closest thing you
could find.
At least, that's the only reason I can come up with for why you'd make such
a wild leap from me trying to connect my interest in the subject with yours
to you claiming I'm talking about or insulting you as a person. Feel free
to correct me if the guess is wrong.
Shayne Wissler
PS: Since you have not gone out of your way to attack me personally very
often, I'm willing to forgive your trespass as long as you don't keep doing
it. I can't say that for one or two others in this forum.
Keith Ray
different Filter classes (which are plugin-modules to an image editor
that we're writing).
Let's say that Image is a concrete class declared thusly:
-------------- Image.h start ------------
class Image
{
public:
Image();
~Image();
int GetPixelAsInt( int x, int y );
// etc...
private
unsigned char* data;
};
-------------- Image.h end ------------
OK. No problem. It doesn't reference any other classes.
Now change that to:
-------------- Image.h start ------------
#include <vector>
class Image
{
public:
Image();
~Image();
int GetPixelAsInt( int x, int y );
// etc...
private
std::vector<unsigned char> data;
};
-------------- Image.h end ------------
Now we've "only" changed the private data, but now we have to #include
the declaration of the template "vector" for the compiler's benefit.
Compiling template code seems to be slower than compiling regular code,
so the compilation speed of the entire project is now slower, because
compiling each of the 30 Filter classes requires the parser to go
through the header file for "vector" 30 times. And even though we've
only changed private data, all those dependant files HAVE to be
recompiled, because the compiler needs to know the size of the Image
object (something not needed in any other OO language except C#) in case
Image objects are used 'by value'.
I've found that #including a single template-laden header into many
files can add several minutes to compile-time.
In practice, you'd probably have vector and many other header files in
your "precompiled headers", so this particular example may not be any
slower. It depends on your platform. You wouldn't want to put your
application's headers in the precompiled headers, because then when-ever
you modified one of your headers, the precompilation would have to be
re-done, AND all of your code would have to be re-compiled.
Tim Ottinger
> It all has to do with how many times the compiler has to parse a header
> file. If a header file is included by 50 classes, it gets parsed 50
> times and every header file it *includes* also gets parsed about 50
> times. That adds up, even though we use "pragma once" in each header.
>
> Dual processor pentium-whatevers, WinNT box, VC++ 6.0, 800 MHz.
I never saw any evidence that 'pragma once' really worked in this regard.
Richard MacDonald
news:104555891...@ersa.uk.clara.net:
>
> "Richard MacDonald" <macdo...@worldnet.att.net> wrote in message
> news:Xns932478E9C8577ma...@204.127.36.1...
>> All anyone can say is that some of the very best
>> programmers are swearing by it and that should be enough for you to
>> try it yourself to see if it works for you.
>
> I can see the appeal - it allows one to abdicate real responsibility
> for optimal return on developement investment over the life of a
> project and get on with the "real work" or programming knowing that
> you are beyond reproach.
1) "Optimal ROI over the life of a project" is marketing nonsense in the
vast majority of situations. Software engineering is simply not yet
sophisticated enough to claim anything of the sort.
2) I said *very best* programmers. I meant it.
Richard MacDonald
> The primary consideration is that it takes us over the boundary of
> what can work with a single process on a single machine. Infact the
> number 200 is only illustrative as the real requirement is to manage
> an "entire access network" which tend to get quite large. If I am to
> attain my goal of designing a near-zero manual administration and yet
> "infinately" scalable network management system I need to sew the
> seeds well ahead of time. With this sort of system the actual business
> logic is less of a problem than issues of sycronisation of various
> data stores and caches and other complexities inherent in highly
> distributes systems.
Ok, so IYO sttcpw leads to a local optimum that is a dead end.
> A points of context: I am not a proponent of waterfall-like Big
> Upfront Design, indeed I would say that in general too much is done up
> front rather than too little so I am sympathetic to attemps to move in
> the other direction - just not to to eliminate any future proofing
> completely.
Ok.
Note to Paul: You could have been a little upfront with this in your
original post :-)
Let me repeat what Ron said:
> First, doing what could possibly work, not what couldn't.
> Second, focusing on simplicity within that context.
Ok, so I didn't mention the need for the first item. My bad, I guess :-/
I was talking about the importance of the second item...*assuming* the
first item.
In your situation, if I knew the approximate architecture requirements
for the 200 nodes, I'd start with that. If I knew a solution for 5 nodes
that wouldn't work for 200 nodes, I *wouldn't do that*...unless this was
exploratory work, in which case I might implement the 5 node solution to
try and learn a few insights.
I'd start with the minimal essence of the 200+ node solution, build it to
run on the minimal node set (2?) and one machine, and go from there. You
know the drill.
FWIW, while we're confessing things, I happen to disagree with the XP
claim that all local optima lead to global optima. I spent many years
developing algorithms for numerical methods in engineering. I was doing
research. The results from one week's work would usually cause a huge
rewrite for the next week's algorithm. So I live with the tendency to
distrust local optimum solutions. But as I continue (in standard crud biz
apps and some complicated wiz bang stuff as well, but no more numerical
methods, sadly), I find I need to reign in this tendency, because so far
it only slows me down today and it hasn't yet bitten me tomorrow. And
I've become pretty darn good at refactoring. Plus code rewriting is
cheap. And throwing away code is more often cause for celebration (I
found a simpler approach, yippee!) than sadness. So I'm now a bigger
believer in nimble-ness than anything else, and I've seen some really
good results in the large when I practice sttcpw in the small.
Ron Jeffries
>
>At least, that's the only reason I can come up with for why you'd make such
>a wild leap from me trying to connect my interest in the subject with yours
>to you claiming I'm talking about or insulting you as a person. Feel free
>to correct me if the guess is wrong.
If you have any questions about Extreme Programming, or comparisons to your
preferred approaches, the time to offer them is now.
Mike Stockdale
advocates writing bad code, and therefore probably never cleans it up.
To me, the green step means: concentrate on getting the functionality
right without worrying about structure. Then, getting the structure
right will be easier because you can see all the code that you need to
structure.
Shayne Wissler
"Ron Jeffries" <ronje...@REMOVEacm.org> wrote in message
> On Wed, 19 Feb 2003 00:15:22 GMT, Shayne Wissler <thal...@yahoo.com>
wrote:
>
> >
> >At least, that's the only reason I can come up with for why you'd make
such
> >a wild leap from me trying to connect my interest in the subject with
yours
> >to you claiming I'm talking about or insulting you as a person. Feel free
> >to correct me if the guess is wrong.
>
> If you have any questions about Extreme Programming, or comparisons to
your
> preferred approaches, the time to offer them is now.
Well, I already provided a comparison. You didn't seem interested in it. Now
you seem to want to pretend that I didn't offer anything for you to
consider. But that is contradicted by your original reply:
> That is a way that some teams build software. I guess you mean that it is
> your preferred way. It is not what XP recommends, and it is not what XP
> teams are actually doing.
What is the "way that some teams build software" Ron? Well, the way I was
advocating. I think it's the right way. If you have any reasons why you
think it isn't, "the time to offer them is now."
Shayne Wissler
Ron Jeffries
>Well, I already provided a comparison. You didn't seem interested in it. Now
>you seem to want to pretend that I didn't offer anything for you to
>consider. But that is contradicted by your original reply:
In this paragraph you are again talking about me, not about the topic.
>> That is a way that some teams build software. I guess you mean that it is
>> your preferred way. It is not what XP recommends, and it is not what XP
>> teams are actually doing.
>
>What is the "way that some teams build software" Ron?
The way you described, Shayne. I acknowledge that some teams work that way. I'm
trying to make it clear that I recognize the things you said as a valid way that
some people use to develop software.
>Well, the way I was
>advocating. I think it's the right way. If you have any reasons why you
>think it isn't, "the time to offer them is now."
I don't think development processes are well-described as "right" and "wrong". I
think software development requires a mix of skills and practices, chosen in the
moment based on the best understanding available at the time.
I'm reporting some techniques that I find useful and that I teach other people
to do. The people who learn these things generally report that they are useful.
You are free to try the techniques, to ignore them, or to ask questions about
them if you haven't decided.
Shayne Wissler
"Ron Jeffries" <ronje...@REMOVEacm.org> wrote in message
> On Wed, 19 Feb 2003 03:25:43 GMT, "Shayne Wissler" <thal...@yahoo.com>
wrote:
>
> >Well, I already provided a comparison. You didn't seem interested in it.
Now
> >you seem to want to pretend that I didn't offer anything for you to
> >consider. But that is contradicted by your original reply:
>
> In this paragraph you are again talking about me, not about the topic.
So why do you keep changing the subject? You're the one who started this, by
implying that I hadn't said anything worth replying to. I'm only responding
to your innuendo. Or do you think it doesn't count as talking about the
person if its through innuendo?
> >> That is a way that some teams build software. I guess you mean that it
is
> >> your preferred way. It is not what XP recommends, and it is not what XP
> >> teams are actually doing.
> >
> >What is the "way that some teams build software" Ron?
>
> The way you described, Shayne. I acknowledge that some teams work that
way. I'm
> trying to make it clear that I recognize the things you said as a valid
way that
> some people use to develop software.
Then I don't understand this comment of yours:
> If you have any questions about Extreme Programming, or comparisons to
your
> preferred approaches, the time to offer them is now.
What was your purpose in stating this? What was your purpose in the snide
remark: "The time to offer them is now."
> >Well, the way I was
> >advocating. I think it's the right way. If you have any reasons why you
> >think it isn't, "the time to offer them is now."
>
> I don't think development processes are well-described as "right" and
"wrong". I
> think software development requires a mix of skills and practices, chosen
in the
> moment based on the best understanding available at the time.
So: XP is not designed by any engineering standard, it does not exist in
order to better achieve an engineering result in relation to other possible
approaches. Well, I'm glad to have you admit that. I guess we can drop this
then. There's no point in arguing with you if you already agree with me.
Shayne Wissler
Phlip
> So: XP is not designed by any engineering standard, it does not exist in
> order to better achieve an engineering result in relation to other
> possible approaches. Well, I'm glad to have you admit that. I guess we can
> drop this then. There's no point in arguing with you if you already agree
> with me.
XP is a form of Objectivism. The Customer Tests, and the Programmer Tests,
provide objective facts about reality, not opinions, which would be subject
to feelings, wishes, hopes or fears.
Basing everything on purely objective data provides more stability than
other systems.
--
Phlip
http://www.greencheese.org/HoneySatellite
-- Got in trouble at StarBucks. I tried to order
"A double latte mocha and a body piercing." --
Shayne Wissler
"Phlip" <phli...@yahoo.com> wrote in message
news:4yE4a.201$zP4.22...@newssvr15.news.prodigy.com...
> Shayne Wissler wrote:
>
> > So: XP is not designed by any engineering standard, it does not exist in
> > order to better achieve an engineering result in relation to other
> > possible approaches. Well, I'm glad to have you admit that. I guess we
can
> > drop this then. There's no point in arguing with you if you already
agree
> > with me.
>
> XP is a form of Objectivism. The Customer Tests, and the Programmer Tests,
> provide objective facts about reality, not opinions, which would be
subject
> to feelings, wishes, hopes or fears.
>
> Basing everything on purely objective data provides more stability than
> other systems.
Beck himself makes reference to Berkeley and Hume as a basis for XP. For
these and other reasons XP is best classified as based on empiricism. BUFD
is a form of rationalism. Objectivism has yet to be applied to software
engineering.
Shayne Wissler
Phlip
> Beck himself makes reference to Berkeley and Hume as a basis for XP. For
> these and other reasons XP is best classified as based on empiricism.
But I thought the objective examination of the facts, not of the author's
religion, could reveal whether a methodology was objective.
Put another way, if you had not heard this rumor about Beck "himself" (who
only barely "invented" XP BTW), would you have been able to backtrack from
the facts to these "Berkeley and Hume" persons?
> BUFD
> is a form of rationalism. Objectivism has yet to be applied to software
> engineering.
Why not yet? And wouldn't such a thing arise whenever any student of
objectivism followed it while writing software?
--
Phlip
http://www.greencheese.org/YaAw
-- "The Epiphany of the Epiphenomenon of the Epiphysis"
- some jerk-off maliciously pretending to be Henry Miller --
Paul Campbell
"Richard MacDonald" <macdo...@worldnet.att.net> wrote in message news:Xns9326D160CA8DCma...@204.127.36.1...
> "Paul Campbell" <p.au.l.ca...@ob.jectvi.sion.c.o.u.k> wrote in
> news:104557745...@ersa.uk.clara.net:
> > logic is less of a problem than issues of sycronisation of various
> > data stores and caches and other complexities inherent in highly
> > distributes systems.
>
> Ok, so IYO sttcpw leads to a local optimum that is a dead end.
Precisely.
>
> > First, doing what could possibly work, not what couldn't.
> > Second, focusing on simplicity within that context.
>
> Ok, so I didn't mention the need for the first item. My bad, I guess :-/
> I was talking about the importance of the second item...*assuming* the
> first item.
>
> In your situation, if I knew the approximate architecture requirements
> for the 200 nodes, I'd start with that. If I knew a solution for 5 nodes
> that wouldn't work for 200 nodes, I *wouldn't do that*...unless this was
> exploratory work, in which case I might implement the 5 node solution to
> try and learn a few insights.
>
> I'd start with the minimal essence of the 200+ node solution, build it to
> run on the minimal node set (2?) and one machine, and go from there. You
> know the drill.
You are doing what I would do - minimal reasonable future proofing, but that is
not STTW.
I interpret the XP position on STTW as Simplest Thing That Works
*Now* - this specifically excludes provision for future requirements and
scalability. I make this assumption becuase of some of the examples of architectural
STTW I have seen put forward by XP-ers such as using a flat file initially instead of
an RDBMS to persist data in an e-commerce system.
The problem I am having with the XP position is the meaning of the word "Works"
is STTW: either it means "Provides well factored but minimally sufficient
fucntionality being delivered now" OR it means "Takes into account future design
and architecture direction in the minimal way that is consistent with being easily
extended in such directions". Now I have seem plenty of quotes from XP people
who say very explicitly that they do not do the latter - they deleberatlt but
future direction out of thier minds. Thus I think I can reasonable conclude that
with the latter defintion of Works, that STTW isnt really STTW at all.
Paul C.
.
Laurent Bossavit
> Ron, the whole point of my post was precisely to indicate some of the
> reasons why an architecture-driven approach is better than the XP approach.
Shayne, I have been reading this exchange carefully. In my opinion,
you have aptly demonstrated that an architecture-driven approach is
superior to one in which
- no effort is made to explore more than a week's worth of
requirements
- no thought is given to what overall technical choices would be
suitable
- stakeholders have no common understanding of the project's business
value.
As far as I can tell, the communication breakdown seems to occur
because you think the latter are accurate statements about XP, while
in Ron's view these statements are in contradiction with the
documented descriptions of XP (*).
There are two further points which seem to me to contribute to
misunderstanding. You state above that you are interested in showing
which approach is "better" than the other. But it seems that at some
point in the thread the conversation drifted from "which is better in
the context of the small problem under consideration
(Salaried/Contractor etc.)" to "which is better", period. Discussions
of "which is better" without consideration of a narrow context are in
general quite fraught.
The other point is Ron's insistence that you address "XP as
documented", which apparently clashes with your not being interested
in "mere re-iteration of what we both know about XP". I'm not sure how
this might be resolved.
(*) It is not impossible that you are both correct: for instance there
might be discrepancies between "XP as documented" and "XP as
practiced", for all sorts of reasons.
Ilja Preuß
compile
> and test time low. I don't see how a program with an abstract base class
plus a
> concrete subclass could possible compile faster than one with just the
concrete
> class.
If you change the concrete class, in a statically typed language all its
clients typically need to be recompiled. You can break this dependency by
letting the clients depend on the abstract base class (which hopefully needs
to get changed less often).
I recently heart Robert Martin say (at a conference in germany) that this is
an important practice in C++, less so in Java.
Regards, Ilja
Ron Jeffries
>Shayne Wissler wrote:
>
>> So: XP is not designed by any engineering standard, it does not exist in
>> order to better achieve an engineering result in relation to other
>> possible approaches. Well, I'm glad to have you admit that. I guess we can
>> drop this then. There's no point in arguing with you if you already agree
>> with me.
>
>XP is ...
Phlip, I suggest that the experiment is over and the result clear.
David B Lightstone
"Jeremy Dunck" <jeremy.remove....@dunck.us> wrote in message
news:967EBC3FB34873FB.731688D5...@lp.airnews.net...
> On Tue, 18 Feb 2003 20:51:37 GMT, "David B Lightstone"
> <david.lightst...@prodigy.net> wrote:
>
> >
> >"Jeremy Dunck" <jeremy.remove....@dunck.us> wrote in message
> <snip>
> >> >>> 4. Simple code minimizes the number of classes and methods used.
> >> >
> >> >Without going back to the source, I think he said "had". Doubtless he
> >meant
> >> >"kept" and "about the program". Ideas about where to have lunch do
not
> >need to
> >> >be recorded in the code. ;->
> >>
> >> are often cited as a code smell, yet I think a comment about why an
> >> alternative approach was -not- taken is a useful thing.
> >
> >Inappropriate for the code, but definitely documentation in need of
being
> >produced. Won't happen on an XP project, however. That is probably
> >mishandled by the pair or in the group bull session
> >
> <snip>
>
> Actually, in my experience, technical specs done before coding rarely
> fortell such implementation issues, and tech specs done in hindsight
> are usually English-ified code, which noone but the coders can
> understand, nor cares to.
It is a question of understanding what information is appropriate at which
time.
>
> As I understand XP, such knowledge is not isolated to a single coder,
> due to the collective ownership.
Word of mouth organizations do not document
Redundance does not assure reliability
>
> It is possible that I've never had the good fortune to work with a
> business analyst or architect worth his pay, and that my experience is
> skewed.
>
> Anyway, I believe that documenting the rationale behind design and
> code decisions is much more valuable than documenting exactly how the
> code what it does. The code is expressive to anyone that cares to
> hear that level of detail, IMHO.
Not disputed. See IEEE Trans on Software jan 2001 edition. The article on
Requirements Traceability by Ramesh and Jarke
>
> Does your experience differ?
Why is more important than how (generally speaking) as it provided
understanding of the tradeoffs. How becomes important when there is a ticky
algorithm (say as an example the Fast Fourier Transform). You have to
understand that which others can reasonably be expected to easily
comprehend. Most of the good hacks just don't have a clue. They are just to
good. (So they create hack oriented methodologies for good hacks and market
them to those who can't readily comprehend)
S Perryman
> On Tue, 18 Feb 2003 16:55:14 GMT, "Shayne Wissler" <thal...@yahoo.com>
wrote:
> >I'll just restate my point: Maybe it would be better to implement part of
> >SalariedEmployee, and part of Contractor, to insure that the architecture
is
> >robust. In general, it's easier to add details to a class than to shift
> >things around to make room for a new one. Refactoring is good, but
avoiding
> >the need for it when you can is even better.
> Maybe it would be better in some sense. What more information would be
needed
> besides the relative costs of both ways, which the programmers produce as
part
> of the planning game, and the understanding of the relative business value
of
> the two ways, which the customer brings to the planning game?
Dependency.
If :
- function/service A1 requires function/service B and C and D
- function/service A2 requires function/service C
then there is the notion that providing A1 before A2 will lessen the
development effort for A1 when the time comes. And vice versa.
Such considerations can be included when defining the
Reasonably complex systems can always be expressed thus (certainly so
on the big systems I've worked on) . And the pre-requisites (B, C etc)
can be further divided if necessary.
Of course, this requires the dirty up-front analysis you people so love.
Unfortunately the corresponding rhetoric you people also love doesn't
hold : the "analysis" spoken of here is broad-brush, is done very
quickly (assuming one has the skills) , and is iterative in nature.
NOT WATERFALL.
Regards,
Steven Perryman
Ron Jeffries
>> Maybe it would be better in some sense. What more information would be
>needed
>> besides the relative costs of both ways, which the programmers produce as
>part
>> of the planning game, and the understanding of the relative business value
>of
>> the two ways, which the customer brings to the planning game?
>
>Dependency.
>
>If :
>
>- function/service A1 requires function/service B and C and D
>- function/service A2 requires function/service C
>
>then there is the notion that providing A1 before A2 will lessen the
>development effort for A1 when the time comes. And vice versa.
>Such considerations can be included when defining the
>
>Reasonably complex systems can always be expressed thus (certainly so
>on the big systems I've worked on) . And the pre-requisites (B, C etc)
>can be further divided if necessary.
Um. The dependency issue is important in terms of cost and time, right?
But the XP planning process, as I just described in the note to which you are
replying, specifically calls for the estimation of the features. And if the
order of development makes a difference in the estimate, then that has to be
expressed.
So, as the previous note tries to say, we tell the customer:
You want A and B. If we do A, then B, A will cost 5 and B will cost 5. However,
if we do B and then A, B will cost 6, but A will be only 3. We can do them in
either order. You decide.
XP planning handles the case you are describing as far as I can see.
>
>Of course, this requires the dirty up-front analysis you people so love.
I think this must be sarcasm but I am not sure. The up front cost analysis
process in XP is called Release Planning. It is mentioned in Extreme Programming
Explained. It is the subject of at least one chapter in Extreme Programming
Installed, and is the subject of approximately half of Planning Extreme
Programming. We do up front cost analysis.
>Unfortunately the corresponding rhetoric you people also love doesn't
>hold : the "analysis" spoken of here is broad-brush, is done very
>quickly (assuming one has the skills) , and is iterative in nature.
>NOT WATERFALL.
Are you saying that you do iterative analysis and XP does not, the reverse, or
something else entirely?
Phlip
> "Phlip" wrote
>> Put another way, if you had not heard this rumor about Beck "himself"
>> (who only barely "invented" XP BTW), would you have been able to
>> backtrack from the facts to these "Berkeley and Hume" persons?
>
> Much "new" human knowledge is simply a refactoring of the old.
You misunderstand my point. Saying "KB says he based XP on the work of B and
H," is an example of "appeal to authority." KB.
I thought Objectivists didn't appeal to authority.
Can one trace XP itself to that of B and H, independently?
The other problem is that Kent Beck only participated in inventing XP. Off
the top of my head, the players included John Brandt, Ward Cunningham,
Martin Fowler, Erich Gamma, Ron Jeffries, Ralph Johnson, Peter Merel, John
Sarkela, Rebecca Wirfs-Brock, etc. All the Smalltalkers, all the original
c2.com Wiki participants, and all the book reviewers get a nod too.
Did every single one of them cite Berkeley and Hume??
--
Phlip
http://www.greencheese.org/InMildDefenseOfTheGnats
-- Friends don't let friends use Closed Source software --
Shayne Wissler
> Peter Kootsookos wrote:
>
> > "Phlip" wrote
>
> >> Put another way, if you had not heard this rumor about Beck "himself"
> >> (who only barely "invented" XP BTW), would you have been able to
> >> backtrack from the facts to these "Berkeley and Hume" persons?
> >
> > Much "new" human knowledge is simply a refactoring of the old.
>
> You misunderstand my point. Saying "KB says he based XP on the work of B
and
> H," is an example of "appeal to authority." KB.
It's not an appeal to authority to point out that the leading XPer refers to
empiricists. It's only a bit of evidence that XP is empiricist. Proving it
would require a detailed analysis of various XP practices and attitudes.
E.g.:
- "Analysis is lying" -- Beck, acting like the disgruntled David Hume
- Refactor to a design; don't form one from the big picture (i.e., don't
use your mind; stare at the code, the "raw facts")
> I thought Objectivists didn't appeal to authority.
It would only be appeal to authority if I considered the reference an
absolute proof in and of itself (but I said "for this and other
reasons...").
> Can one trace XP itself to that of B and H, independently?
>
> The other problem is that Kent Beck only participated in inventing XP. Off
> the top of my head, the players included John Brandt, Ward Cunningham,
> Martin Fowler, Erich Gamma, Ron Jeffries, Ralph Johnson, Peter Merel, John
> Sarkela, Rebecca Wirfs-Brock, etc. All the Smalltalkers, all the original
> c2.com Wiki participants, and all the book reviewers get a nod too.
>
> Did every single one of them cite Berkeley and Hume??
Whether an approach is empiricist is independent of who was cited.
Is there some reason you don't want XP to be empiricist?
Shayne Wissler
Shayne Wissler
"Laurent Bossavit" <laure...@bossavit.com> wrote in message
news:8bb8b7b1.03021...@posting.google.com...
> Shayne wrote:
>
> > Ron, the whole point of my post was precisely to indicate some of the
> > reasons why an architecture-driven approach is better than the XP
approach.
>
> Shayne, I have been reading this exchange carefully. In my opinion,
> you have aptly demonstrated that an architecture-driven approach is
> superior to one in which
> - no effort is made to explore more than a week's worth of
> requirements
> - no thought is given to what overall technical choices would be
> suitable
> - stakeholders have no common understanding of the project's business
> value.
>
> As far as I can tell, the communication breakdown seems to occur
> because you think the latter are accurate statements about XP, while
> in Ron's view these statements are in contradiction with the
> documented descriptions of XP (*).
I'm quite sure that many of my high-level statements about XP would be
rejected by Ron. E.g., my concept of business value flies in the face of
XP's concept, so when I say that XP does not actually work to the standard
of business value, they could ignore my conceptual difference and claim
"Well, the XP literature clearly states that business value is the top
priority." Then they can pretend that I don't know anything about XP.
Another problem is that I'm trying to argue about differences, but most XP
experts only try to find commonalities. I say that architecture should be
the top priority, so they respond that architecture is important, and ignore
or do not look for any difference between what I am advocating and their own
approach. They seem more interested in smoothing over differences than in
actually understanding them.
I can only guess that the reason why they shun holding the differences up to
the light is that they think it will make XP look bad. Either that or
they're uncomfortable with disagreement. "Why can't we all just get along?"
> There are two further points which seem to me to contribute to
> misunderstanding. You state above that you are interested in showing
> which approach is "better" than the other. But it seems that at some
> point in the thread the conversation drifted from "which is better in
> the context of the small problem under consideration
> (Salaried/Contractor etc.)" to "which is better", period. Discussions
> of "which is better" without consideration of a narrow context are in
> general quite fraught.
Well, I think I gave a fair indication of the context: complex, new
projects, lasting more than a month. I agree that this is a bit woozy, but
it does exclude quite a bit. E.g., maintenance, and projects that you can
sling together with whatever method in a few weeks.
> The other point is Ron's insistence that you address "XP as
> documented", which apparently clashes with your not being interested
> in "mere re-iteration of what we both know about XP". I'm not sure how
> this might be resolved.
I'm only asking that we don't have a *mere* reiteration. A reiteration is
fine as long as it's for the purpose of highlighting differences,
understanding, and evaluating them.
Shayne Wissler
Phlip
> Is there some reason you don't want XP to be empiricist?
No. I already know it's not those silly bad things you listed, so I don't
care what ism you give it.
--
Phlip
http://www.c2.com/cgi/wiki?PhlIp
-- Have a :-) day --
Richard MacDonald
news:RDO4a.177910$HN5.7...@rwcrnsc51.ops.asp.att.net:
> I can only guess that the reason why they shun holding the differences
> up to the light is that they think it will make XP look bad. Either
> that or they're uncomfortable with disagreement. "Why can't we all
> just get along?"
I'm not sure I should post this, given that I'm supposed to be the one
who hijacks threads off-topic, but this triggered a strong thought:
I know of two major styles of learning/improving: (1) Let's take what is
working and broaden it. (2) Let's focus on fixing what isn't working.
I think Shayne is like I was 12 yrs ago: Back then I felt type-2 was the
most important and therefore the only way to function. In fact, I didn't
even know that type-1 was valid. Then I discovered I made a bad captain
and coach of a sports team, I was introduced to type-1, and it hit me
hard because I had never considered it.
While I'm still a type-2 at heart, in many ways type-1 is better for a
team. This is certainly a way-overgeneralization, but I see a lot of
type-1 in XP and type-2 in the opposition. XP says to take what is
working and crank it up to 11! That is clearly type-1. The opposition is
harder to categorize: Without going so far as BDUF, much of the argument
is to say "if something is wrong with the existing operation, fix it
directly". That is type-2. E.g., if the requirements are wrong, spend
more time with the customer; if the implementation is wrong, do a better
job with analysis and design; if the code is buggy, beef up the testing.
(There is another style of opposition argument which doesn't conveniently
fit into 1 or 2 categorization: "Because something is not perfect, it is
therefore *wrong* and *totally useless*". A fixation with idealism and
perfection. This is definitely Shayne. As a pragmatic engineer, I find
this approach *totally useless* (:-); that fantasy is beaten out of every
engineer the first college exam they take. Yet there is a large number of
superior people in IT who think exactly this way. The best programmer I
know has a fit when I make a statement that is only 99.9% correct. We
have to put the conversation on hold for as much time as it takes to nail
down that last 0.1%. 100% of the time! Obviously, this attitude is
valuable when dealing with the idiot savants we call computers.
Unfortunately, its also a hindrance when it comes to those human-infected
things we call software development teams.)
As far as the thread hijacking, simply step back one post and
continue...thank you for your readership.