Some XP Questions
Phlip
> I am trying to convince my manager that XP may be the
> way to go however I have some reservations about it
> and need clarification on the following points:
Good. All this stuff has been around the list server, so I'l soften up the
target before one of the founders takes over.
> 1. XP claims not to need "great" programmers in order
> to deliver. How competent do people have to be to
> do XP? (Think people who never read a computing
> book or magazine and have no CS degree, ie normal
> corporate programmers as a baseline.)
http://c2.com/cgi/wiki?TheCoach
> 2. XP claims to produce good design as a side-effect of
> the refactoring process. I may be wrong but a 2000
> class Pay Roll system sounds like a *poor* design.
> Sorry but this is my gut feel, 2000 classes is really
> huge, battle ship management maybe not pay roll!
> Please convince me I'm wrong.
Would you prefer one class with 2,000 methods?
http://c2.com/cgi/wiki?RefactorMercilessly
"RefactorMercilessly" says to constantly improve structure. _Not_ constantly
chop up classes. But guess what? lots of small simple classes work better
and are more understandable. Perhaps you are familiar with this...
http://c2.com/cgi/wiki?StovepipeAntiPattern
...and you think that "lots of little classes" means they are all listed in
a row somewhere, and a God Object manipulates them.
> 3. What are examples of System Metaphore? This
> seems to be key but silent. Say what would you use
> as the metaphore for a Financial Credit Risk System?
http://c2.com/cgi/wiki?LibraryOfMetaphors
Metaphors got a discussion on the XP list server; they lamented this gap in
the existing docs.
Focus on the goal: A bridge between concepts. C3 used the "car assembly
line" metaphor because it had nothing to do with payrolls. This forced
programmers to invent a dialect based on the metaphor that the customers
could instantly understand. They are the ones who must not feel outside the
loop (no matter how hard they try to get there).
> 4. When I've done up front design for system components
> (eg DB access method, realtime datafeeds etc) it's
> paid off big time. However when I second guess the
> customer on business stuff it's hit and miss at best.
> The second aligns with XP dogma the first does not.
The first does too. You know what the ultimate destination of the code is.
Getting there in many small steps (each profitable) improves the result.
Have you ever worked on the results of a WaterFall project, where months of
abstract coding then magically come together, and everything works just
right without excess features?
> Is the fact that Smalltalk has a vast and pretty comprehensive
> library the reason XP seems to not need the first type of
> design?
Nope. Perl's got a bigger library. Who does XP in Perl?
And always remember that "Buy Don't Build" trumps every XP practice.
> 5. Designs that really simplify a system are often non-obvious
> and at the core require some amount of complexity.
> Andrew Koenig talks of "Simplicity through Complexity".
> XP bans this approach. (I guess this is reprise of 4)
>
> Are XP designs often clean but sub-optimal?
Define clean. Define optimal. Repeat until there's no difference.
> 6. Is co location with all the users good enough vs a user on
> the XP team?
An appointed team member with the user's concerns at heart is enough.
> 7. How small can an XP team be and still function? We have
> very small teams 1, 2 ,3 people.
http://c2.com/cgi/wiki?SoloPartnering
Are there more than one "team" on your project? That may indicate
specialization. OTOH PairProgramming is only a goal if you have enough to
pair. If you have 3, mix and match them.
> I'm serious about XP. It aligns well with the way I have to work
> to get anything done. In short it promises to work in the normal
> dysfunctional organisation.
Then do every single practice that you need no permission for, but spare
time to patch up the practices that got left out. For example, if your house
does not do daily builds, moving to ContinuousIntegration is obviously out
of the question. But you will need to work extra to get ready for the
Monthly Builds and their IntegrationHell parties...
> I'm convinced on the testing, the pair programing,
> the user on the team, the small releases etc but not
> the above.
Then you are convinced about the elements that support the elements you are
not convinced about. And these elements support the ones you are convinced
about. What a tightrope!
> Please reply via email as well as to the group as my server
> still loses lots of messages.
Can you use www.deja.com? or
http://www.egroups.com/group/extremeprogramming ?
> --my opinions only
I'm certain I'm about to hear which ones are only mine, too. ;-)
--
Phlip
======= http://users.deltanet.com/~tegan/home.html =======
Nick Thurn
way to go however I have some reservations about it
and need clarification on the following points:
1. XP claims not to need "great" programmers in order
to deliver. How competent do people have to be to
do XP? (Think people who never read a computing
book or magazine and have no CS degree, ie normal
corporate programmers as a baseline.)
2. XP claims to produce good design as a side-effect of
the refactoring process. I may be wrong but a 2000
class Pay Roll system sounds like a *poor* design.
Sorry but this is my gut feel, 2000 classes is really
huge, battle ship management maybe not pay roll!
Please convince me I'm wrong.
3. What are examples of System Metaphore? This
seems to be key but silent. Say what would you use
as the metaphore for a Financial Credit Risk System?
4. When I've done up front design for system components
(eg DB access method, realtime datafeeds etc) it's
paid off big time. However when I second guess the
customer on business stuff it's hit and miss at best.
The second aligns with XP dogma the first does not.
Is the fact that Smalltalk has a vast and pretty comprehensive
library the reason XP seems to not need the first type of
design?
5. Designs that really simplify a system are often non-obvious
and at the core require some amount of complexity.
Andrew Koenig talks of "Simplicity through Complexity".
XP bans this approach. (I guess this is reprise of 4)
Are XP designs often clean but sub-optimal?
6. Is co location with all the users good enough vs a user on
the XP team?
7. How small can an XP team be and still function? We have
very small teams 1, 2 ,3 people.
I'm serious about XP. It aligns well with the way I have to work
to get anything done. In short it promises to work in the normal
dysfunctional organisation.
I'm convinced on the testing, the pair programing,
the user on the team, the small releases etc but not
the above.
Please reply via email as well as to the group as my server
still loses lots of messages.
thanks in advance
Nick
--my opinions only
Patrick D. Logan
Nick Thurn wrote:
>
> 1. XP claims not to need "great" programmers in order
> to deliver. How competent do people have to be to
> do XP? (Think people who never read a computing
> book or magazine and have no CS degree, ie normal
> corporate programmers as a baseline.)
My opinion, not based on experience with XP per se, makes me believe
that if they are successful without XP they will be successful with
XP. And if they consult someone with XP experience they may even be
*more* successful with XP.
If they are not successful already, they need to consult someone who
*is* successful, and it may as well be someone experienced with XP.
(Depending on their abilities, "consulting" may be as simple as
participating in Usenet discussions.)
> 2. XP claims to produce good design as a side-effect of
> the refactoring process. I may be wrong but a 2000
> class Pay Roll system sounds like a *poor* design.
> Sorry but this is my gut feel, 2000 classes is really
> huge, battle ship management maybe not pay roll!
> Please convince me I'm wrong.
I won't be able to help here, except to say it is too simple to base
this assumption on the number of classes, so it is good you are asking
for more information.
I will also add that having worked in a large corporation roughly the
size of Chrysler, it is not inconceivable to me that a payroll
application might be very complex.
> 3. What are examples of System Metaphore? This
> seems to be key but silent. Say what would you use
> as the metaphor for a Financial Credit Risk System?
I think you have to play with the concepts for a bit to come up with a
good metaphor. People in that domain, or programmers who've been
successful in that domain would probably generate the best ideas.
One idea that comes to my mind is a scale: on the one hand you have
factors leading the business to want to approve the credit; on the other
hand you have factors leading the business to want to disapprove the
credit. Putting weights on either side will "tip the scale" one way or
the other.
> 4. When I've done up front design for system components
> (eg DB access method, realtime datafeeds etc) it's
> paid off big time. However when I second guess the
> customer on business stuff it's hit and miss at best.
> The second aligns with XP dogma the first does not.
Both fit XP. The first phase of an XP project is "exploration" which
includes exploring the technological risks of the project. If you have
to access a database or a system in a way that is not familiar to the
team, then that is a risk and is explored in order to better estimate
the feasibility of that technology and the teams comfort in estimating
the effort required to use it.
> Is the fact that Smalltalk has a vast and pretty comprehensive
> library the reason XP seems to not need the first type of
> design?
No. XP does need it, even if you use Smalltalk. Java has a growing
library of interfaces to databases and systems too. If the team is
not familiar with the needed interfaces, they need to experiment.
> 5. Designs that really simplify a system are often non-obvious
> and at the core require some amount of complexity.
> Andrew Koenig talks of "Simplicity through Complexity".
> XP bans this approach. (I guess this is reprise of 4)
>
> Are XP designs often clean but sub-optimal?
I don't see why XP would lead to sub-optimal designs per se. For one
thing, XP is tailored for you to put in only what the customer wants.
The design rules will lead you to the "simplest thing that could
possibly work" according to XP's definition of "simple".
When the customer indicates a priority for a certain level of
performance you will have a simple design that can be evaluated
for performance. At this point you make just the changes necessary to
get the performance the customer wants when the customer wants it.
Of course if there *are* certain performance needs, it is best to get
that information up front. This lets you experiment with the desired
technology as well as with the architectural aspects you think will
affect performance. This is all explained in the XP book.
> 6. Is co location with all the users good enough vs a user on
> the XP team?
I think the *goal* of XP is to get requirements decisions ASAP. The
means XP proposes is to have the customer on the team. I think each
team has to reach the goal using the best means available to them.
> 7. How small can an XP team be and still function? We have
> very small teams 1, 2, 3 people.
Maybe you would want to have at least two people on a team. But there
has been stuff written about single-person XP. See the Wiki at
http://www.c2.com
> I'm serious about XP. It aligns well with the way I have to work
> to get anything done. In short it promises to work in the normal
> dysfunctional organisation.
I don't see how it does so. I think it promises to work for a team
that is determined to function well even if their environment does
not function well. The team needs to be good, though.
--
Patrick Logan
patric...@home.com
Nick Thurn
Nick Thurn wrote in message <8a1k3n$dn0$1...@kilmer.bain.oz.au>...
>I am trying to convince my manager that XP may be the
>way to go however I have some reservations about it
>and need clarification on the following points:
>
8. Demarco and Lister talk of "flow" and the need for quiet
no distractions etc when programming. Brooks (I think)
mentions a study showing those who programmed while listening
to music were not as fully engaged as they thought and
missed some simplifying insights that those who worked in
silence usually found (at least in the study problems).
If we are to Pair Program are we programing at full potential
or like the music listeners only half engaged? Does this matter
in XP?
My manager is opposed to Pair Programing. I am not
OTOH I suspect it is of more value in forcing communication,
design/knowledge dispersal and making work more fun than
actually being a better way to program.
thanks again
Nick
Phlip
>
> 8. Demarco and Lister talk of "flow" and the need for quiet
> no distractions etc when programming. Brooks (I think)
> mentions a study showing those who programmed while listening
> to music were not as fully engaged as they thought and
> missed some simplifying insights that those who worked in
> silence usually found (at least in the study problems).
>
> If we are to Pair Program are we programing at full potential
> or like the music listeners only half engaged? Does this matter
> in XP?
You'v probably read this:
http://c2.com/cgi/wiki?MentalStateCalledFlow
SoloProgramming is non-verbal flow. Your speech centers get swapped out
of core storage. (That's what makes verbal interruptions so impossible
to service.)
But PairProgramming is verbal flow, with your speech centers still
online. Practice makes perfect!
> My manager is opposed to Pair Programing. I am not
> OTOH I suspect it is of more value in forcing communication,
> design/knowledge dispersal and making work more fun than
> actually being a better way to program.
The word is either your boss micro-manages you, or brief pairing spells are
permitted within your own discretion. The first thing any manager confronted
by XP will say is, "But we don't have the resources", as if PP were some
secret plot to double the cost of software research. And coders doing it
will generally report "It makes me feel faster."
"And don't underestimate the importance of Body Language! Hah!" --
UrsulaTheSeaWitch
Robert C. Martin
Nick Thurn <nick....@db.com> wrote in message
news:8a1k3n$dn0$1...@kilmer.bain.oz.au...
> I am trying to convince my manager that XP may be the
> way to go however I have some reservations about it
> and need clarification on the following points:
>
> to deliver. How competent do people have to be to
> do XP? (Think people who never read a computing
> book or magazine and have no CS degree, ie normal
> corporate programmers as a baseline.)
This is just like anything else. The better the programmers, the better the
outcome. Doing XP with great programmers will have great results. Doing XP
with average programmers will have average results (compared to other XP
projects). Average programmers can use XP to great benefit, but great
programmers will dervive even more benefit.
> 2. XP claims to produce good design as a side-effect of
> the refactoring process. I may be wrong but a 2000
> class Pay Roll system sounds like a *poor* design.
> Sorry but this is my gut feel, 2000 classes is really
> huge, battle ship management maybe not pay roll!
> Please convince me I'm wrong.
200,000 lines of code (as I recall), 2000 classes, 100 lines of code per
class. This sounds like a good ratio to me. Perhaps you are thinking that
a payroll system should not be 200,000 lines of code. If so, I think it's
safe to say that you've never studied payroll systems.
Does XP automatically generate good design? No, XP is a process. The
designs that come out of an XP project are only as good as the designers can
make them. However, XP does several things to encourage the designers to
produce the best designs they can. 1) Short iterations with continual
feedback allow the designers to find their errors and repair them before
they are too entrenched. 2) Pair programming ensures that designs are
created by the team rather than the individual. 3) Simple Design Principles
provide guidlines for designers to avoid unecessary infrastructure and
duplication. 4) An emphasis on refactoring helps developers to continuously
improve the design.
>
> 3. What are examples of System Metaphore? This
> seems to be key but silent. Say what would you use
> as the metaphore for a Financial Credit Risk System?
Unknown. Sometimes the metaphor is not discovered until weeks or months
into the project. Often the metaphor is completely orthogonal to the
problem domain. In large projects there may be several interlocking
metaphors.
A metaphor is a system of names and relationships that gives the design a
conceptual integrity. Once in place, designers immediately know how to name
new classes or methods because they draw from the metaphor.
For example, I once worked on a multi-user system where a stream of
characters had to be sent down a serial link. We used a double-buffered
process such that as one buffer was being filled from the character source,
the other was being sent down the serial link. When the sending buffer
emptied, the two buffers swapped places.
I tried to explain this to a colleague. At first he had trouble visualizing
the system. Then, suddenly, he exclaimed: "It's like two dump trucks!
While one is being loaded from a big pile of dirt, the other is dumping that
dirt into a pit. When the dumping truck is empty it drives back to the
pile. When the loading truck is full, it drives to the pit.
This metaphor made sense to him, but it also allowed him to play games with
the concept. He started questioning the number of trucks, or whether or not
there could be more than one pile or pit. He started considering the
effects of multiple stops for the trucks, and priorities on the trucks, etc.
The concept of a truck dispatcher was discussed.
Once a metaphor is in place, it provides the system of names and the
essential relationships that the developers can use to discuss the solution.
Finding that metaphor, or a system of interlocking metaphors, is a
challenge. Often the best way to find them is to start working on the
project.
>
> 4. When I've done up front design for system components
> (eg DB access method, realtime datafeeds etc) it's
> paid off big time. However when I second guess the
> customer on business stuff it's hit and miss at best.
> The second aligns with XP dogma the first does not.
>
> Is the fact that Smalltalk has a vast and pretty comprehensive
> library the reason XP seems to not need the first type of
> design?
No. XP does not do up front design because it is speculative. Parts of it
will be wrong. Rather, XP does "Just in time design". We create designs
for exactly what we know we are going to need. No more, no less. We do
that design just as we are writing the code. In effect, the code is our
detailled design modeling language. We consider code to be just as flexible
and effient a modeling language as UML. Sometimes, if need be, a pair, or a
team, might sit down and draw some UML diagrams in order to coordinate their
actions over the next couple of days. Those diagrams are discarded once
everyone understands the design.
Design pays off big time. It is XP's contention that "Just in time design"
pays off even better than "Big Up front design" does.
> 5. Designs that really simplify a system are often non-obvious
> and at the core require some amount of complexity.
> Andrew Koenig talks of "Simplicity through Complexity".
> XP bans this approach. (I guess this is reprise of 4)
>
> Are XP designs often clean but sub-optimal?
XP does not ban the result! In XP, complexity is added whenever needed. If,
by adding complexity to parts of the code, the overall design can be
simplified, then that is what XPers will do. However, they don't do it up
front when it would be speculative. They do it right when they need it.
Does this mean that they must rework a lot of the code? Sometimes, yes.
But XPers are not afraid to rework the code. XP contends that it is cheaper
to rework the code to support a better design than it is to suffer through
specualtive up-front designs.
>
> 6. Is co location with all the users good enough vs a user on
> the XP team?
No, a customer (i.e. someone with the authority and responsibility to define
requirements) must be allocated to the team. This person's first priority
is to communicate with the team, supplying requirements, writing functional
tests, and answering questions.
> 7. How small can an XP team be and still function? We have
> very small teams 1, 2 ,3 people.
Unknown. There are teams in the UK that have three people.
> I'm serious about XP. It aligns well with the way I have to work
> to get anything done. In short it promises to work in the normal
> dysfunctional organisation.
XP requires committment and discipline from both developers and customers.
While many customers and developers often like what XP seems to offer them;
don't underestimate the resistance you may get. Developers may refuse to
pair. Customers may refuse to give you a full time team member. Testing
may lose its priority. Refactoring may drop by the wayside. Developers may
drop back into owning their own code. etc. etc. If you want to use XP, be
prepared to defend the practices.
--
Robert C. Martin | "Uncle Bob" | Training Courses:
Object Mentor Inc. | rma...@objectmentor.com | OOD, Patterns, C++, Java,
PO Box 85 | Tel: (800) 338-6716 | Extreme Programming.
Grayslake IL 60030 | Fax: (847) 548-6853 | http://www.objectmentor.com
"One of the great commandments of science is:
'Mistrust arguments from authority.'" -- Carl Sagan
Robert C. Martin
> >way to go however I have some reservations about it
> >and need clarification on the following points:
> >
>
>
> no distractions etc when programming. Brooks (I think)
> mentions a study showing those who programmed while listening
> to music were not as fully engaged as they thought and
> missed some simplifying insights that those who worked in
> silence usually found (at least in the study problems).
>
> If we are to Pair Program are we programing at full potential
> or like the music listeners only half engaged? Does this matter
> in XP?
>
> OTOH I suspect it is of more value in forcing communication,
> design/knowledge dispersal and making work more fun than
> actually being a better way to program.
Show your manager the pair programming studies.
http://www.cs.utah.edu/~lwilliam/Papers/ The Costs and Benefits paper is
particularly good.
Pairing is a way of *intensifying* focus. In a pair, one person becomes the
coder, the other the strategic thinker and manager of resources. The coder
is busy at the keyboard writing the code that the two have agreed upon. His
partner is watching the code being produced, checking its syntax and
semantics. He knows what the coder is about to write and makes sure the
appropriate API manuals are open to the right page for the coder to use,
etc, etc. It's like two runners that pace each other -- focus is
intensified not diminished.
Patrick D. Logan
Nick Thurn wrote:
>
> 8. Demarco and Lister talk of "flow" and the need for quiet
> no distractions etc when programming. Brooks (I think)
> mentions a study showing those who programmed while listening
> to music were not as fully engaged as they thought and
> missed some simplifying insights that those who worked in
> silence usually found (at least in the study problems).
They were probably not even considering pair programming in their
evaluation.
> If we are to Pair Program are we programing at full potential
> or like the music listeners only half engaged? Does this matter
> in XP?
I would think it matters a lot in XP. XP says it promotes what it
does because it has been observed to work best. In my own experience,
every time I program with someone the result is better.
> My manager is opposed to Pair Programing. I am not
> OTOH I suspect it is of more value in forcing communication,
> design/knowledge dispersal and making work more fun than
> actually being a better way to program.
If your manager prefers improvement over tradition, and is open to
trying new things in a moderate way, then you might suggest an
experiment. Set aside some of your time for pair programming. Allow
enough time to adjust, and ask questions of the XP experts. If it
works, keep doing it, maybe even more of the time. If it doesn't
work, discontinue the experiment and congratulate yourselves for
trying.
--
Patrick Logan
patric...@home.com
Jim McFarland
<rma...@objectmentor.com> wrote:
>
>Nick Thurn <nick....@db.com> wrote .
>> 4. When I've done up front design for system components
>> (eg DB access method, realtime datafeeds etc) it's
>> paid off big time. However when I second guess the
>> customer on business stuff it's hit and miss at best.
>> The second aligns with XP dogma the first does not.
>>
>> Is the fact that Smalltalk has a vast and pretty comprehensive
>> library the reason XP seems to not need the first type of
>> design?
>
>No. XP does not do up front design because it is speculative. Parts of it
>will be wrong. Rather, XP does "Just in time design". We create designs
>for exactly what we know we are going to need. No more, no less. We do
>that design just as we are writing the code. In effect, the code is our
>detailled design modeling language. We consider code to be just as flexible
>and effient a modeling language as UML. Sometimes, if need be, a pair, or a
>team, might sit down and draw some UML diagrams in order to coordinate their
>actions over the next couple of days. Those diagrams are discarded once
>everyone understands the design.
So where does CRC fit in? Your comments here make it seem that no
design is done until the coding starts. That is not what I have read
or done with XP. It may happen some times, but not all of the time
with all XP teams.
You talk about code and UML. What about CRC cards? Do you really
believe C++ is just as flexible a modeling language as UML (or CRC
cards)? Maybe some languages would be, but not all OO languages. I
sure find it easier to move around and edit some CRC cards than to
write code.
And I want to add that not all who do XP throw away all diagrams.
Much of what Robert is saying here is what he does or advocates and
not part of the "rules" and practices of XP. The XP literature is not
that specific.
>
>Design pays off big time. It is XP's contention that "Just in time design"
>pays off even better than "Big Up front design" does.
Just in time design, to me, means you don't do speculative design, but
it does not mean no design is done up front. Just because an XP team
does not do BigDesignUpFront, it doesn't mean they do no design up
front. By up front I am meaning before writing code, whether at the
start of a project or at the start of an iteration or before
implementing an engineering task. I agree that design does happen
while coding and during refactoring, but it also happens before
writing tests and other code. At least for me it does... and I don't
see that as being non-XP.
later...
jim
Jim McFarland (j.mcf...@computer.org)
Member of ACM
http://www.acm.org/
Member IEEE Computer Society
http://www.computer.org/
Ronald E Jeffries
wrote:
>2. XP claims to produce good design as a side-effect of
> the refactoring process. I may be wrong but a 2000
> class Pay Roll system sounds like a *poor* design.
> Sorry but this is my gut feel, 2000 classes is really
> huge, battle ship management maybe not pay roll!
> Please convince me I'm wrong.
I once thought payroll was simple too. It turns out that it is
essentially complex, because of all the special deals and weird
practices that have been set up over years of union negotiations and
HR people with strange ideas.
For example, these are pretty accurate:
People in Dayton get paid differently from people anywhere else.
Ex-Jeep employees accrue certain benefits six months out of phase with
everyone else - or is it a year.
There are five people whose union dues are different from anyone else.
No, really.
There are about seven unions, each with different dues rules.
The UPGWA (you-pig-wa) United Plant Guard Workers of America have two
tiers of workers, based on time of hire. The old guard (sorry) get a
better deal than the new ones.
There are something like 5 different savings plans, with accounts
before and after taxes, matched and unmatched, each with maximum and
minimum contribution based on company and government policy.
Health insurance includes one of those menu deals where you can pick
all kinds of combinations. And there's FLEX, where they give you money
you can use for all kinds of medical stuff.
The wage attachment system is a separate knowledge-based system that
must be talked to over sockets.
The Human Resources information (wage base, hiring dates, etc) is a
separate relational database that must be queried as the payroll runs.
There are several hundred unique transactions that can come into the
system. Each must be done in order, and must be separately accounted
for. They all can be wrong so each must have unique validation.
If the employee doesn't get enough money to pay all his deductions
(something we've all worried about as we look at the tax items), there
is a special order in which things must be taken. Some are totally
taken, some partially, some have to be skipped. There is no logic to
this. The employee is last on this list, of course. I am not making
this up.
Everything has to generate transactions for the general ledger. The
general ledger keeps accounts completely differently from payroll, so
they're all special calculations.
There are approximately 3,000 unique fields of information produced
for each paycheck, going downstream to various COBOL programs. Most of
these fields are complex, i.e. they are some strange calculation like
(base pay unless the guy is on sick leave, in which case it's his
number of children) (well, almost). They are variously output in
EBCDIC, COMP-3, etc. The program runs on an ASCII machine.
There are approximately 50 states and 300 communities' taxes to be
dealt with, including reciprocity. (If you work in A and live in B,
you can pay the lower of the two communities' taxes. But if you live
in B and work in A ...).
There's profit-sharing, which is calculated based on a formula made up
days before the checks come out, and having little relationship to
anything previously computed.
There's the Disability program. After being sick for 3 days (when your
pay comes from your normal account), you go on disability, where your
pay continues but comes from another account. After N days you only
get 60% of your pay, unless you come back and go out on a different
disability. Payroll is never informed when someone comes back from
disability until after at least one check has gone out based on the
wrong account. So the payroll has to back out the figures from the
disability account and apply them to the regular. Then it turns out
the guy isn't back after all.
Transfers to and from this payroll to one of the other six (6) occur
at random. You have to accept whatever useless input they give you and
simulate the guy being in your better payroll from the beginning. If
he leaves, you have to pack up your info and stuff it into the few
smashed-together fields the other old program wants. If the guy
transfers back, they want to use any good data you may have but to
simulate the rest.
Sometimes they get two copies of the same individual in the system for
a while, sometimes in the same payroll, sometimes in different ones.
You have to sort it out.
Well ... that's all I can remember offhand ... I haven't worked there
for almost a year. But you get the idea.
Ron Jeffries
http://www.XProgramming.com
Meditation is futile. You will be aggravated.
Nick Thurn
Phlip wrote in message <8a335d$p...@chronicle.concentric.net>...
>Nick Thurn wrote:
>>
>> 8. Demarco and Lister talk of "flow" and the need for quiet
>> no distractions etc when programming. Brooks (I think)
>> mentions a study showing those who programmed while listening
>> to music were not as fully engaged as they thought and
>> missed some simplifying insights that those who worked in
>> silence usually found (at least in the study problems).
>>
>> or like the music listeners only half engaged? Does this matter
>> in XP?
>
No I haven't thanks for the reference.
>SoloProgramming is non-verbal flow. Your speech centers get swapped out
>of core storage. (That's what makes verbal interruptions so impossible
>to service.)
>
>But PairProgramming is verbal flow, with your speech centers still
>online. Practice makes perfect!
>
>> My manager is opposed to Pair Programing. I am not
>> OTOH I suspect it is of more value in forcing communication,
>> design/knowledge dispersal and making work more fun than
>> actually being a better way to program.
>
>The word is either your boss micro-manages you, or brief pairing spells are
>permitted within your own discretion.
"All is permitted, nothing is forbidden". This is part of the problem.
I am trying to avoid the "institutional fix", a big M methodology
(disguised as little m) landing splat on all of us.
>The first thing any manager confronted
>by XP will say is, "But we don't have the resources",
No my manager is recalling solo programming on VAX
in Pascal and VAX Basic.
Nick Thurn
Robert C. Martin wrote in message ...
>> to deliver. How competent do people have to be to
>> do XP? (Think people who never read a computing
>> book or magazine and have no CS degree, ie normal
>> corporate programmers as a baseline.)
>
>This is just like anything else. The better the programmers, the better
the
>outcome. Doing XP with great programmers will have great results. Doing
XP
>with average programmers will have average results (compared to other XP
>projects). Average programmers can use XP to great benefit, but great
>programmers will dervive even more benefit.
>
Ok, I'm getting the feeling from your response and Patrick's that
the programmers have to be at least what people in comp.object
would call "real programmers".
>> 2. XP claims to produce good design as a side-effect of
>> the refactoring process. I may be wrong but a 2000
>> class Pay Roll system sounds like a *poor* design.
>> Sorry but this is my gut feel, 2000 classes is really
>> huge, battle ship management maybe not pay roll!
>> Please convince me I'm wrong.
>
>200,000 lines of code (as I recall), 2000 classes, 100 lines of code per
>class. This sounds like a good ratio to me. Perhaps you are thinking that
>a payroll system should not be 200,000 lines of code. If so, I think it's
>safe to say that you've never studied payroll systems.
>
Very true which is why I'm asking.
My reaction to 2000 classes is because the 85,000 lines system
I currently work on (which has only about 200 classes) replaces a
system that did much less (250 positions vs 35,000 positions,
5 products vs 20 products, no market data vs market data capture,
no curves vs own curves). The old system had 500 classes and
200,000 lines and on top of that was unstable and a nighmare to
follow.
I'll happily grant that the current system could be better (which is why
I have a job!) but I doubt it would be better by splitting all classes
into 5 others.
Booch and others have stated that proliferation of classes and classes
that do too little are a problem. I attended a seminar where someone
described their system as having 2500 classes. Booch went
uncharacteristically quiet for a time then said "Is it as simple as it
could be?".
Stroustrup talks of the "gargantuism" of poorly designed systems.
So I don't think I'm alone in being suspicious of BIG systems.
Having said that I am not a SmallTalker and perhaps 1000 of
the classes in c3 are CollectionOfSomeClass or EnumerationOf...
or some other idiomatic usage. In my 200 class system
I count the BRef<T> template as 1 not another 164 and std::map
not at all. Maybe I'm cheating! ;-)
>>
>> 3. What are examples of System Metaphore? This
>> seems to be key but silent. Say what would you use
>> as the metaphore for a Financial Credit Risk System?
>
>Unknown. Sometimes the metaphor is not discovered until weeks or months
>into the project. Often the metaphor is completely orthogonal to the
>problem domain. In large projects there may be several interlocking
>metaphors.
>
Can you give an example where the metaphore is orthogonal to the
problem domain?
>A metaphor is a system of names and relationships that gives the design a
>conceptual integrity. Once in place, designers immediately know how to
name
>new classes or methods because they draw from the metaphor.
>
Just as an aside: isn't this why others advocate using the "real world"
as the basis for the names and relationships of a design? After all
you already have this metaphore from day one.
>> 4. When I've done up front design for system components
>> (eg DB access method, realtime datafeeds etc) it's
>> paid off big time. However when I second guess the
>> customer on business stuff it's hit and miss at best.
>> The second aligns with XP dogma the first does not.
>>
>> Is the fact that Smalltalk has a vast and pretty comprehensive
>> library the reason XP seems to not need the first type of
>> design?
>
>No. XP does not do up front design because it is speculative. Parts of it
>will be wrong. Rather, XP does "Just in time design".
But upfront design of a system mechanism may be "Just in time" to
avoid much wailing and gnashing of teeth due to proliferation of
say db access code in business classes?
It's hardly speculative to say "we need a read write add and
delete mechanism". Speculative would be "we only have
Sybase but let's make it work with Oracle and Ingres and be
transparent to GemStone and POET"?
>Design pays off big time. It is XP's contention that "Just in time design"
>pays off even better than "Big Up front design" does.
>
We may be a cross purposes here. I am not a BUFD advocate but
I prefer to know as much as possible before starting. Once started
code/design/test/ask all seems to blur together until clarity and
clean working code emerges.
Like Kent Beck says in his book the *last* thing you do before
you switch out the lights on the project is write the 10 page document
that gives the next guy a road map to your system.
>>
>> 6. Is co location with all the users good enough vs a user on
>> the XP team?
>
>No, a customer (i.e. someone with the authority and responsibility to
define
>requirements) must be allocated to the team. This person's first priority
>is to communicate with the team, supplying requirements, writing functional
>tests, and answering questions.
>
Ok let's say your customer is say chief Trader or Quant. They're not
going to move to Siberia (across the road to IT-land) but you could
move to them. Your answer suggests that the problem of user's
refusing to be engaged with the process (a pretty common
problem in finance, at least in my experience) is not helped by XP.
>XP requires committment and discipline from both developers and customers.
>While many customers and developers often like what XP seems to offer them;
>don't underestimate the resistance you may get. Developers may refuse to
>pair. Customers may refuse to give you a full time team member. Testing
>may lose its priority. Refactoring may drop by the wayside. Developers
may
>drop back into owning their own code. etc. etc. If you want to use XP, be
>prepared to defend the practices.
>
Ok so XP can help but as with all other methods the first step
is the hardest one: "fix the organisation".
Thanks very much for you help.
cheers
Nick
Patrick D. Logan
Nick Thurn wrote:
>
> Can you give an example where the metaphore is orthogonal to the
> problem domain?
"Orthogonal" in this context means "independent". I can give an
example: the decision to approve credit can be like a scale where you
tip the scale toward approval or disapproval by adding "weight" to
either side of the decision. Credit and scales are independent of each
other, but the more complex domain can be understood in terms of the
simpler domain.
> Just as an aside: isn't this why others advocate using the "real world"
> as the basis for the names and relationships of a design? After all
> you already have this metaphore from day one.
Except that *sometimes* a simpler metaphor can simplify a more complex
real world problem. Why stick to the literal domain when a metaphorical
domain might be better?
--
Patrick Logan
patric...@home.com
Nick Thurn
Phlip wrote in message <8a1nu8$3...@chronicle.concentric.net>...
>"RefactorMercilessly" says to constantly improve structure. _Not_
constantly
>chop up classes. But guess what? lots of small simple classes work better
>and are more understandable. Perhaps you are familiar with this...
>
> http://c2.com/cgi/wiki?StovepipeAntiPattern
>
Yes but what has it to do with the question? I would say a system
with all it's data wrapped up in an object database looks suspiciously
like a stovepipe. :-|
>...and you think that "lots of little classes" means they are all listed in
>a row somewhere, and a God Object manipulates them.
>
No, why do you say this?
>Metaphors got a discussion on the XP list server; they lamented this gap in
>the existing docs.
>
>Focus on the goal: A bridge between concepts. C3 used the "car assembly
>line" metaphor because it had nothing to do with payrolls. This forced
>programmers to invent a dialect based on the metaphor that the customers
>could instantly understand. They are the ones who must not feel outside the
>loop (no matter how hard they try to get there).
>
This is helpful. The metaphore is not necesssarily from the problem
domain, got it.
Why does this remind me of the "bears" and "bunnies" hidden in
the bowels of MS Dos code? ;-)
>> 4. When I've done up front design for system components
>> (eg DB access method, realtime datafeeds etc) it's
>> paid off big time. However when I second guess the
>> customer on business stuff it's hit and miss at best.
>> The second aligns with XP dogma the first does not.
>
>The first does too. You know what the ultimate destination of the code is.
>Getting there in many small steps (each profitable) improves the result.
>Have you ever worked on the results of a WaterFall project, where months of
>abstract coding then magically come together, and everything works just
>right without excess features?
>
I've never worked on a waterfall project in my life but I've had a
lot of managers tell me this is the only way to go. (Just for the record
I disagree big time and have prototyped since the 80's)
>And always remember that "Buy Don't Build" trumps every XP practice.
>
Agreed.
>> 5. Designs that really simplify a system are often non-obvious
>> and at the core require some amount of complexity.
>> Andrew Koenig talks of "Simplicity through Complexity".
>> XP bans this approach. (I guess this is reprise of 4)
>>
>> Are XP designs often clean but sub-optimal?
>
>Define clean. Define optimal. Repeat until there's no difference.
>
Clean: readable and easily understandable by humans other
than the author.
Optimal: minimum overhead both conceptually and operationally
If the system is not clean then it is very hard to get anywhere.
Even if it is clean the requirement to do a huge refactoring
may mean it is never optimal. When a user requirement or
system usage change arrives that requires the optimal design
then there is a long lag before delivery as the system must
effectively be rewritten. Granted this will be easier with a test
suite in place.
If the requirement for optimal never comes then you don't
pay for optimal. I would contend that optimal and sub optimal
cost the same except when you implement sub-optimal first.
(No I don't mean the C programmers everything faster than
everything else == "optimal")
So a method that produces sub-optimal designs will
cost more over time due to rework where rework turns
into rewrite. Example implement in Java then try to port
the innards to C++ when it doesn't scale.
>> 6. Is co location with all the users good enough vs a user on
>> the XP team?
>
>An appointed team member with the user's concerns at heart is enough.
>
Hmmm.. don't accept this. Sounds like mind reading.
>> 7. How small can an XP team be and still function? We have
>> very small teams 1, 2 ,3 people.
>
> http://c2.com/cgi/wiki?SoloPartnering
>
>Are there more than one "team" on your project? That may indicate
>specialization. OTOH PairProgramming is only a goal if you have enough to
>pair. If you have 3, mix and match them.
>
No, in my world everything that moves is *meant* to be a project.
This includes maintainence activities.
The issue is: "this is bollocks".
One part of the organisation has tackled this. The Director took the
list of 200 "projects" and said "pick five". Magically the other 195
either coagulated into the 5 or disappeared.
I don't work in that enlightened area (and incidently neither does
anyone else as they outsourced the 5 projects!).
Teams are really small because the business area "owns" their
IT people. This leads to StovePipes and really variable results
across teams.
cheers
Nick
--my opinions only
Patrick D. Logan
Nick Thurn wrote:
>
> But upfront design of a system mechanism may be "Just in time" to
> avoid much wailing and gnashing of teeth due to proliferation of
> say db access code in business classes?
Yes. I would call this an "up front experiment"
>
> It's hardly speculative to say "we need a read write add and
> delete mechanism". Speculative would be "we only have
> Sybase but let's make it work with Oracle and Ingres and be
> transparent to GemStone and POET"?
That's a good example.
> Ok so XP can help but as with all other methods the first step
> is the hardest one: "fix the organisation".
I think XP may help you fix the organization by providing structure
for at least your team and those who need to interact with it. Any
group doing business with your team will know the rules.
--
Patrick Logan
patric...@home.com
Phlip
> I once thought payroll was simple too. It turns out that...
<2,000 absurd "business" rules snipped>
Has anyone tried explaining something to the unions and governments? If
everyone negotiated a single, flat, simple, pseudo-socialist deal without
any special cases anywhere, Chrysler could sack a whole lot of very
expensive computer scientists, unplug rooms full of very expensive hardware,
and divvy the savings up among...
Naw, never mind...
Phlip
> No, why do you say this?
A> It hinged on the "Perhaps" above the URL break.
B> It's the only answer I know for the question so far ;-)
> This is helpful. The metaphore is not necesssarily from the problem
> domain, got it.
Robert's example was incredible. A group of simple data queues might grow to
need a dedicated scheduler. And the person who realized this was a civilian,
thinking about dump trucks, who realized many trucks often need a
dispatcher. Amazing.
Who says programmers are hard to understand?
> Why does this remind me of the "bears" and "bunnies" hidden in
> the bowels of MS Dos code? ;-)
Wha?
> I've never worked on a waterfall project in my life but I've had a
> lot of managers tell me this is the only way to go.
But have you seen the resulting code?
> (Just for the record
> I disagree big time and have prototyped since the 80's)
Before or after the 3-month probation period?
> >And always remember that "Buy Don't Build" trumps every XP practice.
>
> Agreed.
Ron called me out on that. BDB trumps any dev effort _after_ you can find a
library with a close match and no stumbling blocks. Unless if you are
padding your resume...
> Clean: readable and easily understandable by humans other
> than the author.
> Optimal: minimum overhead both conceptually and operationally
Great. Now repeat _applying_ the definitions to source, over and over again.
> If the system is not clean then it is very hard to get anywhere.
And the difficulties inspire pairs to inspect the dirt, identify ways to
clean it, and commit the change.
(We are down to fairly close agreement over standard XP rhetoric here, so
I'l snip it all to leave space on the servers for porn.)
> Teams are really small because the business area "owns" their
> IT people. This leads to StovePipes and really variable results
> across teams.
NBCi fixed that by unifying the team & permitting project executives to
submit requests to the team lead. Then a month later they sold the team to
US Web.
Nick Thurn
Ronald E Jeffries wrote in message ...
>Well ... that's all I can remember offhand ... I haven't worked there
>for almost a year. But you get the idea.
>
Yes I think I do. When I started in finance I thought "It can't be
this hard?" Gradually I accepted it was, but even these days
I sometimes think I've been seduced by the "dark-side" ;-)
Thanks for the response,
cheers
Nick
Robert C. Martin
Jim McFarland <j.mcf...@computer.org> wrote in message
news:p3hacsk7ub6gor7ci...@4ax.com...
> On Tue, 7 Mar 2000 08:52:15 -0600, "Robert C. Martin"
> <rma...@objectmentor.com> wrote:
>
> >
> >Nick Thurn <nick....@db.com> wrote .
> >> (eg DB access method, realtime datafeeds etc) it's
> >> paid off big time. However when I second guess the
> >> customer on business stuff it's hit and miss at best.
> >> The second aligns with XP dogma the first does not.
> >>
> >> Is the fact that Smalltalk has a vast and pretty comprehensive
> >> library the reason XP seems to not need the first type of
> >> design?
> >
> >No. XP does not do up front design because it is speculative. Parts of
it
> >will be wrong. Rather, XP does "Just in time design". We create designs
> >for exactly what we know we are going to need. No more, no less. We do
> >that design just as we are writing the code. In effect, the code is our
> >detailled design modeling language. We consider code to be just as
flexible
> >and effient a modeling language as UML. Sometimes, if need be, a pair,
or a
> >team, might sit down and draw some UML diagrams in order to coordinate
their
> >actions over the next couple of days. Those diagrams are discarded once
> >everyone understands the design.
>
Same place. Some people like UML, some like CRC. Both serve the same
purpose.
> Your comments here make it seem that no
> design is done until the coding starts. That is not what I have read
> or done with XP. It may happen some times, but not all of the time
> with all XP teams.
In an XP project, programming starts as soon as we have enough user stories
to give the user a valuable release; and it never ceases thereafter.
Programming is broken up into releases, then iterations, then tasks, then
tests cases. At each of these divisions some design options may be
considered; but only those design options that impact on the immediate
issue. The investigation of design issues may use CRC, or UML, or the
writing of exploratory code.
> You talk about code and UML. What about CRC cards?
CRC cards work too.
> Do you really
> believe C++ is just as flexible a modeling language as UML (or CRC
> cards)?
For some purposes, yes. I use UML at a whiteboard while concocting design
options with others. I use UML in Visio when writing articles or books.
> Maybe some languages would be, but not all OO languages. I
> sure find it easier to move around and edit some CRC cards than to
> write code.
Granted. On the other hand there is a point at which you learn a lot more,
and a lot faster, by committing the design to code. XP errs on the side of
early code.
> And I want to add that not all who do XP throw away all diagrams.
The term 'discarded' means simply that XP does not consider the diagrams
valuable. You can do what you like with them.
> Much of what Robert is saying here is what he does or advocates and
> not part of the "rules" and practices of XP. The XP literature is not
> that specific.
If you talk to Kent, he'll tell you that in XP you can draw any kind of
diagram you like, so long as you don't keep it. Also, look at page 112 in
"Extreme Programming: Embrace Change" where Kent says: "...we don't save
the pictures once they have had their effect on the code...".
> >Design pays off big time. It is XP's contention that "Just in time
design"
> >pays off even better than "Big Up front design" does.
>
> Just in time design, to me, means you don't do speculative design, but
> it does not mean no design is done up front. Just because an XP team
> does not do BigDesignUpFront, it doesn't mean they do no design up
> front. By up front I am meaning before writing code, whether at the
> start of a project or at the start of an iteration or before
> implementing an engineering task. I agree that design does happen
> while coding and during refactoring, but it also happens before
> writing tests and other code. At least for me it does... and I don't
> see that as being non-XP.
Small bits of design work are done immediately prior to programming. During
iteration planning, the team is designing as they break the stories into
tasks. During a development episode, a pair is designing as they think up
of test cases. This is all "up front" so to speak. But it is also "just in
time."
Nick Thurn
Phlip wrote in message <8a4pui$a...@journal.concentric.net>...
>Nick Thurn wrote:
>
>> Why does this remind me of the "bears" and "bunnies" hidden in
>> the bowels of MS Dos code? ;-)
>
>Wha?
>
or such. At least that's my recollection, the 70's are even hazier... ;-]
>> Clean: readable and easily understandable by humans other
>> than the author.
>> Optimal: minimum overhead both conceptually and operationally
>
>Great. Now repeat _applying_ the definitions to source, over and over
again.
>
Sure but optimal may not be "the simplest thing that could possibly
work" and it may be totally conceptually different
eg your system has a large number of small calculations and rules:
Design A: implement as objects using strategy pattern,
chain of responsibilities, buracracy etc
Design B: implement a parser and data access method
with the calcs as data (scripts) held by a generic
calc object and rules as holders of sets of calcs.
B may be optimal as the system can be "finished" with
respect to the project team much sooner (hence lower
development cost) with changes to the system a user
configuration issue rather than a program design issue.
But B is more complex at it's core than the approach of A.
A may be optimal as users make less mistakes as the system
is designed to do the right thing and doesn't let them stuff
up their data. But A has more of a conceptual overhead
than B and requires much more internal plumbing.
Getting from B -> A or A -> B would probably be a big job.
I'm not convinced that the patter of refactoring rain drops
mercilessly or otherwise would get you to A from B
or B from A.
Once an overall design is in place it represents a
directional commitment that is a big job to change.
I'm sure refactoring will make it as good as it can
be in that direction but I'm not convinced refactoring
would allow you to change direction at the macro level,
which may be necessary sometimes.
I guess what I'm getting at is the cost of a macro
change may still be high.
Ell
#Small bits of design work are done immediately prior to programming. During
#iteration planning, the team is designing as they break the stories into
#tasks. During a development episode, a pair is designing as they think up
#of test cases. This is all "up front" so to speak. But it is also "just in
#time."
Up-front has customarily meant overall study of the background and needs of
requirement and their scenarios (stories). It's the opposite of doing it in
small bits. Further it means designing the overall solution business model,
for the most part after, having done background study and unit design of at
least all major requirements.
Elliott
Robert C. Martin
> rmartin said of C3.
> >200,000 lines of code (as I recall), 2000 classes, 100 lines of code per
> >class. This sounds like a good ratio to me.
> My reaction to 2000 classes is because the 85,000 lines system
> I currently work on (which has only about 200 classes)
C3 was Smalltalk. 100 lines per class in smalltalk translates (very
roughly) to 400+ lines of code per class in C++. You have about 425 lines
per class. So I imagine the conceptual load of C3's classes is roughly
equivalent to the conceptual load of your classes (presuming yours are in
C++).
> Booch and others have stated that proliferation of classes and classes
> that do too little are a problem. I attended a seminar where someone
> described their system as having 2500 classes. Booch went
> uncharacteristically quiet for a time then said "Is it as simple as it
> could be?".
Software projects are getting very large. 2500 classes is not an indictment
if the project is a a megaline or so. Our alternative is to make the
classes get bigger, which is also known to be a problem.
In short, you cannot judge a system solely by its size. You have to
understand whether the complexity matches the size.
> >>
> >> 3. What are examples of System Metaphore? This
> >> seems to be key but silent. Say what would you use
> >> as the metaphore for a Financial Credit Risk System?
> >
> >Unknown. Sometimes the metaphor is not discovered until weeks or months
> >into the project. Often the metaphor is completely orthogonal to the
> >problem domain. In large projects there may be several interlocking
> >metaphors.
>
> Can you give an example where the metaphore is orthogonal to the
> problem domain?
Did you read the dumptruck metaphore I posted elsewhere?
>
> >A metaphor is a system of names and relationships that gives the design a
> >conceptual integrity. Once in place, designers immediately know how to
> name
> >new classes or methods because they draw from the metaphor.
> >
>
> Just as an aside: isn't this why others advocate using the "real world"
> as the basis for the names and relationships of a design? After all
> you already have this metaphore from day one.
Yes. However, the language of the problem is not always (often) the best
metaphor for the solution. The solution requires *mechanism* that the
problem often does not talk about.
>
> >> 4. When I've done up front design for system components
> >> (eg DB access method, realtime datafeeds etc) it's
> >> paid off big time. However when I second guess the
> >> customer on business stuff it's hit and miss at best.
> >> The second aligns with XP dogma the first does not.
> >>
> >> Is the fact that Smalltalk has a vast and pretty comprehensive
> >> library the reason XP seems to not need the first type of
> >> design?
> >
> >No. XP does not do up front design because it is speculative. Parts of
it
> >will be wrong. Rather, XP does "Just in time design".
>
> But upfront design of a system mechanism may be "Just in time" to
> avoid much wailing and gnashing of teeth due to proliferation of
> say db access code in business classes?
You have two options here. Design the DB framework and hope that people
find it useful; or wait until people start using the DB and find out exactly
what would be useful. XP chooses the latter approach.
> It's hardly speculative to say "we need a read write add and
> delete mechanism".
Are there any aspects of the API that *are* speculative?
> Speculative would be "we only have
> Sybase but let's make it work with Oracle and Ingres and be
> transparent to GemStone and POET"?
Speculative may also be the structure of the APIs, the arguments and names
of the functions.
>
> >Design pays off big time. It is XP's contention that "Just in time
design"
> >pays off even better than "Big Up front design" does.
> >
>
> We may be a cross purposes here. I am not a BUFD advocate but
> I prefer to know as much as possible before starting. Once started
> code/design/test/ask all seems to blur together until clarity and
> clean working code emerges.
This works even when you don't know as much as possible before starting; and
may even be faster that way.
>
> Like Kent Beck says in his book the *last* thing you do before
> you switch out the lights on the project is write the 10 page document
> that gives the next guy a road map to your system.
>
> >>
> >> 6. Is co location with all the users good enough vs a user on
> >> the XP team?
> >
> >No, a customer (i.e. someone with the authority and responsibility to
> define
> >requirements) must be allocated to the team. This person's first
priority
> >is to communicate with the team, supplying requirements, writing
functional
> >tests, and answering questions.
> >
>
> Ok let's say your customer is say chief Trader or Quant. They're not
> going to move to Siberia (across the road to IT-land) but you could
> move to them. Your answer suggests that the problem of user's
> refusing to be engaged with the process (a pretty common
> problem in finance, at least in my experience) is not helped by XP.
Regardless of who moves where, an XP team needs close, high priority,
contact with the "customer". If such contact cannot be had, XP is not
likely to succeed; but then again, I doubt that any process would fare well.
>
> >XP requires committment and discipline from both developers and
customers.
> >While many customers and developers often like what XP seems to offer
them;
> >don't underestimate the resistance you may get. Developers may refuse to
> >pair. Customers may refuse to give you a full time team member. Testing
> >may lose its priority. Refactoring may drop by the wayside. Developers
> may
> >drop back into owning their own code. etc. etc. If you want to use XP,
be
> >prepared to defend the practices.
> >
>
>
> Ok so XP can help but as with all other methods the first step
> is the hardest one: "fix the organisation".
This is the essential dilemma of our existence.
todd...@my-deja.com
"Robert C. Martin" <rma...@objectmentor.com> wrote:
> > But upfront design of a system mechanism may be "Just in time" to
> > avoid much wailing and gnashing of teeth due to proliferation of
> > say db access code in business classes?
>
> You have two options here. Design the DB framework and hope that
people
> find it useful; or wait until people start using the DB and find out
exactly
> what would be useful. XP chooses the latter approach.
Even though you probably have written a DB framework 5 times
before you still need to wait? Why is it you can't reuse that
experience immediately on a new project? In fact, it's that
experience that should guide what people are doing, not vice
verse. We don't let new mountain climbers pick a route up
the mountain.
I'm very interested to know where this line of reasoning stops.
Because you will draw a line somewhere. Your line of tossing
great dump trucks full of experience away on each new project
does not make any sense at all to me.
Do you create a new language for every project? Do you write
a compiler from scratch on each project? Do you toss
all standard c++ or smalltalk libraries before each project?
You may say this is sillyness and these are obviously
different than the other parts of a project, but i don't see
a difference at all. Or you might say if we really felt it necessary
you really would create a new language etc, but i wouldn't believe
this for a second. Given your logic for the database framework you must
start from scratch in almost all areas because you won't know what
you really need until you start. A database framework or a dozen
other common project artifacts are no different.
> > Like Kent Beck says in his book the *last* thing you do before
> > you switch out the lights on the project is write the 10 page
document
> > that gives the next guy a road map to your system.
On many products the lights are never turned off. New bulbs
are constantly beeing added, replaced, moved, and going
on maternity leave. The turn out the lights notion
is one a consultant may have, but it doesn't work for ongoing
concern.
Sent via Deja.com http://www.deja.com/
Before you buy.
Ronald E Jeffries
>Even though you probably have written a DB framework 5 times
>before you still need to wait? Why is it you can't reuse that
>experience immediately on a new project? In fact, it's that
>experience that should guide what people are doing, not vice
>verse.
I've written a database framework, indeed entire commercial database
products, several times. Each of them had different market focus and
needed different features with different priorities, sometimes quite
radically different priorities. The order of doing things was quite
different every time.
Writing a product that USES database facilities is even more
problematical. The purpose of the product is not to be a database, but
to deliver business value to the customer.
XP focuses on delivering value as rapidly as possible, and uses other
means (refactoring etc) to ensure that we don't get cornered.
So if we could give the customer a usable subset that only read from
the database, we'd do it. We wouldn't build the writing part of the
framework until the customer's value said he wanted his product to do
something like writing.
It's tempting to fear that we'll get in trouble if we don't do the
whole framework, but that's another topic from WHY we don't. We don't
because (a) we can do it incrementally without getting cornered, and
(b) if we just do the part we need, we can give valuable software to
our customer sooner.
Here's a time I learned that lesson in a particularly hard way. We
were writing an app that needed a database. We had the best database
available for what we were doing. We bought it, didn't build it.
It slowed us down to use it, because though it was the simplest, it
was still complex to use. It slowed down the product, because though
it was the fastest, it was still too slow for our app. We wound up
ripping it out and building our own lightweight, fast database.
If we had built incrementally from the beginning, instead of letting
our fear that we needed a database take control of us, we'd have
gotten done sooner with better results. By better results I mean that
we could have delivered a better product sooner - quite likely soon
enough to avoid going out of business. Live and learn.
I'm no longer afraid of waiting to build framework as I need it.
That's a technical problem and an easy way to work. I'm afraid of not
delivering real value to my customer ASAP. That's why I do things the
way I do.
Regards,
Patrick D. Logan
Ronald E Jeffries wrote:
>
> Here's a time I learned that lesson in a particularly hard way. We
> were writing an app that needed a database. We had the best database
> available for what we were doing. We bought it, didn't build it.
>
> It slowed us down to use it, because though it was the simplest, it
> was still complex to use. It slowed down the product, because though
> it was the fastest, it was still too slow for our app. We wound up
> ripping it out and building our own lightweight, fast database.
>
> If we had built incrementally from the beginning, instead of letting
> our fear that we needed a database take control of us, we'd have
> gotten done sooner with better results. By better results I mean that
> we could have delivered a better product sooner - quite likely soon
> enough to avoid going out of business. Live and learn.
Could you describe the characteristics of the database you did build
and how long it took to build it? I no longer feel the need to build
big frameworks, however I have trouble thinking about building even the
simplest database when there are so many available already.
After all, C3 uses Gemstone. Why?
--
Patrick Logan
patric...@home.com
Robert Oliver
> Even though you probably have written a DB framework 5 times
> before you still need to wait? Why is it you can't reuse that
> experience immediately on a new project? In fact, it's that
> experience that should guide what people are doing, not vice
> verse. We don't let new mountain climbers pick a route up
> the mountain.
1. If we are writing yet-another-DB-framework for the sixth time and some
of the other 5 frameworks are still in use, should we not consider
refactoring the existing product(s) to remove duplication? (OAOO) The
problem with this approach is that it constrains changes that can be made
to the framework and increases the scope of testing to include each of the
other products that use the framework. Not a small price to pay. We need
to be careful.
2. When we decide to write another DB framework we should at least be able
to "borrow" code and tests from another source. Maybe we will need to
write new tests. If the tests can be written to use the previous terms and
names, etc. we might be able to pull in classes "as is" to incorporate as
needed. IMO, old code (especially if it has unit tests) is a really good
resource and could easily be TheSimplestThingThatCouldPossiblyWork.
However, this may introduce a good deal of legacy code into the new
system. Testing and understanding legacy code could be an order of
magnitude harder than starting from scratch.
3. For new code we write, YAGNI is basically about sequencing the work of
programming to provide the most bang for the buck at each instance of
time. We just don't write things that aren't needed now. If they are
needed at all, they will be written then. YAGNI is not
You'reNeverGonnaNeedIt.
Comments?
Regards,
Bob Oliver
todd...@my-deja.com
<697EFD8FBD617ABA.EB45023B...@lp.airnews.net>,
Ronald E Jeffries <ronje...@acm.org> wrote:
> On Thu, 09 Mar 2000 15:29:07 GMT, todd...@my-deja.com wrote:
> I've written a database framework, indeed entire commercial database
> products, several times. Each of them had different market focus and
> needed different features with different priorities, sometimes quite
> radically different priorities. The order of doing things was quite
> different every time.
If you had really done your system metaphore, CRC sessions, etc, then
it should be quite easy to know pretty what you will need.
If it's not easy then i agree completely, stay away from
it until you know more about what you are doing. Most
systems however are far from novel. Novel elements can
be attacked early and enthusiastically. They will yield
their secrets.
> Here's a time I learned that lesson in a particularly hard way. We
> were writing an app that needed a database. We had the best database
> available for what we were doing. We bought it, didn't build it.
>
> It slowed us down to use it, because though it was the simplest, it
> was still complex to use. It slowed down the product, because though
> it was the fastest, it was still too slow for our app. We wound up
> ripping it out and building our own lightweight, fast database.
I got in a car accident once. I still drive. I drive better now.
Most of the time i don't get in accidents.
The problems you had were characteristics of the database, not
the interface to the database.
If you would have created an abastract database interface then
you could have easily ripped it out and put in whatever you wanted.
Very easy. In fact we've done the several times on my current
project and not drop of developer code had to change. We do it all
the time with new hardware interfaces. You were bit in the ass
because you tied your code tightly to the database. Duh.
> I'm no longer afraid of waiting to build framework as I need it.
Certainly, by definition frameworks will change and be extended.
But why this should not preclude using other approaches too is not
at all clear. You seem to have a phobia because because you have been
traumatized in the past. A phobia is not a basis for a
methodology. Especially when it explicitly excludes other
approaches that repeatedly show their value.
> That's a technical problem and an easy way to work. I'm afraid of not
> delivering real value to my customer ASAP. That's why I do things the
> way I do.
Ok, don't do anything that doesn't bring customer value. The
decision then rests on what you consider real and what you consider
value. By creating an abstract database interface you have created
great value because developers can code to interface and you can
change the implementation any time you want. If you are saying
even after 10 years of writing database interfaces you can't come
up with a database interface then i don't know what to say.
It's demonstratably possible. As it is for a great number of
common project related frameworks.
Ronald E Jeffries
>The problems you had were characteristics of the database, not
>the interface to the database.
>If you would have created an abastract database interface then
>you could have easily ripped it out and put in whatever you wanted.
>Very easy. In fact we've done the several times on my current
>project and not drop of developer code had to change. We do it all
>the time with new hardware interfaces. You were bit in the ass
>because you tied your code tightly to the database. Duh.
No,with all due respect, I was isolating my code from my libraries
before you were born. (before most people were born, anyway ...)
The mistake was in selecting a database at all. We really did have the
very best one - we had carefully explored them. The time spent ramping
up on database connection, then trying to optimize it, when what we
really needed was far less powerful than a database, was the mistake.
The point, in response to the original posting regarding why not build
a framework first, was and is: building a framework doesn't deliver
business value to the customer. Too much time building framework can
put you down. And, building a framework is NOT necessary to get a
well-structured system out the other end.
Ronald E Jeffries
<patric...@home.com> wrote:
>Could you describe the characteristics of the database you did build
>and how long it took to build it? I no longer feel the need to build
>big frameworks, however I have trouble thinking about building even the
>simplest database when there are so many available already.
Varialble length records in a variable tree structure. Many reads /
few writes. Incremental writes, ability to back out single updates one
at a time (Undo). Definitely NOT relational, not aggregate oriented
but element oriented. Good object database app, but the object
database was overkill. I don't remember how long it took to build what
we needed, but it didn't take as long as WYSIWYG tax forms portable
across all possible PCs, printers and video cards.
For a relational-like app, I'd use some ODBC database (or the
mainframe if need be). Unless sequential files with a twist would
work.
>After all, C3 uses Gemstone. Why?
Got me hangin'. It was there when I got there.
Doing it again, we'd do it in Smalltalk and use a much more serial
structure. Payroll is basically a cumulative write process ... once
you pay a guy, you never update that check's info ... you just cut
another check, possibly void a past one. When you void, you delta it
out, you don't erase the past. So the only updates of history you'd
ever do would be to compress out detail information from time to time,
i.e. every N years. A growing series of variable structure blobs would
do it. GemStone saves everything - it really is a live object
database. As such, it saves more than payroll needs and slows you down
for this kind of app. Good system, though, don't get me wrong.
todd...@my-deja.com
<C541960B8827809D.D7205642...@lp.airnews.net>,
>
> >The problems you had were characteristics of the database, not
> >the interface to the database.
> >If you would have created an abastract database interface then
> >you could have easily ripped it out and put in whatever you wanted.
> >Very easy. In fact we've done the several times on my current
> >project and not drop of developer code had to change. We do it all
> >the time with new hardware interfaces. You were bit in the ass
> >because you tied your code tightly to the database. Duh.
>
> No,with all due respect,
If they say its not about the sex, it's about the sex. If
they say with all due respect, they mean no respect.
>I was isolating my code from my libraries
> before you were born. (before most people were born, anyway ...)
You didn't this time and you paid for it. Could it be senescence?
> The mistake was in selecting a database at all.
Not true. This is a phobic reaction to past framework induced
trauma. It is very curable.
>We really did have the
> very best one - we had carefully explored them
That's not even the point. You know up front that most
software sucks and that you may have to toss it. This
is now an axiom. Making your system dependent on the database
was the mistake. Consequently the conclusion not to ever
build frameworks does not hold.
>then trying to optimize it, when what we
> really needed was far less powerful than a database, was the mistake.
It's not the database. It's how you used it in your system.
You used it in a way that guaranteed failure if that risk point
turned negative. Perfectly predicatable. Perfectly
preventable.
> The point, in response to the original posting regarding why not build
> a framework first, was and is: building a framework doesn't deliver
> business value to the customer.
Not true again. Many many examples proving this incorrect. If
you define your database debacle as a framework then we are in
complete agreement. You should never build a framework like that,
ever. Fortunately what you did was not a framework.
>Too much time building framework can put you down.
Trivially true. Too much time doing anything is bad. As
goldilocks found out, there is a way that is not too cold
and not too hot.
>And, building a framework is NOT necessary to get a
> well-structured system out the other end.
Again trivially true. No one could ever argue that it's
necessary.
Samuel T. Harris
Robert did say '"up front" so to speak'.
By that, I took his meaning to be design work is done before coding.
I also took his meaning to be that the design work was not done
"up front" in the classical sense. That "so to speak"
part clued me in that he meant something related, but different
from the customary meaning. I guess his quotes around "up front"
help me see that as well.
And how do you associate small bits being the opposite of up front?
Programming in the large requires divided activities, including
design activities. So design is classically done in bits which
are integrated together to form a single design. Its news to me
when you say up front means no bits and pieces!
--
Samuel T. Harris, Principal Engineer
Raytheon, Aerospace Engineering Services
"If you can make it, We can fake it!"
Nick Thurn
Robert C. Martin wrote in message ...
>
>> problem domain?
>
>Did you read the dumptruck metaphore I posted elsewhere?
>
small in scope. The "car assembly line" from Phlip's
post seems more generative ie covers greater system scope.
>> But upfront design of a system mechanism may be "Just in time" to
>> avoid much wailing and gnashing of teeth due to proliferation of
>> say db access code in business classes?
>
>You have two options here. Design the DB framework and hope that people
>find it useful; or wait until people start using the DB and find out
exactly
>what would be useful. XP chooses the latter approach.
>
This is a real problem for me. Experience tells me that you
have to write MUCH more code when you don't have a standard
framework. Hence the (and I'm talking small and simple here)
framework reduces the work load.
When I say framework I usually mean simplification, narrowing
standardising and hiding, not expansion. I have seen the opposite
(eg one data vendor replaced their 10 function C library with a wopping
300 class monstrosity) and I dislike it big time. Perhaps I
should say standard interface instead, in line with OnceAndOnceOnly?
>> It's hardly speculative to say "we need a read write add and
>> delete mechanism".
>
>Are there any aspects of the API that *are* speculative?
>
There's a line where it gets just plain silly to define something
as speculative. Other's comments about only *ever* doing
what the customer asks for sometimes cross this line,
eg the customer doesn't want any security
so you don't put it in. The auditors then don't allow you
to go into production. The customer is happy working
with UAT as Production so you do it but Sys Admin
use UAT for other stuff on the weekends and power
off the server without restarting your system.
You lose data and the user hates you (or at least IT in
general). I've lived through this one.
>> Ok so XP can help but as with all other methods the first step
>> is the hardest one: "fix the organisation".
>
>This is the essential dilemma of our existence.
>
>
Agreed.
Patrick D. Logan
Ronald E Jeffries wrote:
>
> >Could you describe the characteristics of the database you did build
> >and how long it took to build it? I no longer feel the need to build
> >big frameworks, however I have trouble thinking about building even the
> >simplest database when there are so many available already.
>
> Varialble length records in a variable tree structure. Many reads /
> few writes. Incremental writes, ability to back out single updates one
> at a time (Undo). Definitely NOT relational, not aggregate oriented
> but element oriented. Good object database app, but the object
> database was overkill. I don't remember how long it took to build what
> we needed, but it didn't take as long as WYSIWYG tax forms portable
> across all possible PCs, printers and video cards.
Sounds like a record manager, not a database per se. I would hesitate
to build instead of buy, but YMMV.
> >After all, C3 uses Gemstone. Why?
>
> Doing it again, we'd do it in Smalltalk and use a much more serial
> structure. Payroll is basically a cumulative write process ... once
> you pay a guy, you never update that check's info ... you just cut
> another check, possibly void a past one. When you void, you delta it
> out, you don't erase the past. So the only updates of history you'd
> ever do would be to compress out detail information from time to time,
> i.e. every N years. A growing series of variable structure blobs would
> do it.
This is something that has struck me about nearly all the business
applications I have been a part of over the last 20 years. There is
very little modify in place, a lot of read-only history, and updating
which values are cinsidered current.
--
Patrick Logan
patric...@home.com
Patrick D. Logan
todd...@my-deja.com wrote:
>
> You know up front that most software sucks and that you may have to
> toss it. This is now an axiom.
Sad but true.
--
Patrick Logan
patric...@home.com
Robert C. Martin
<todd...@my-deja.com> wrote in message news:8a8fvr$k3k$1...@nnrp1.deja.com...
> In article <sceitk...@news.supernews.com>,
> > > avoid much wailing and gnashing of teeth due to proliferation of
> > > say db access code in business classes?
> >
> > You have two options here. Design the DB framework and hope that
> people
> > find it useful; or wait until people start using the DB and find out
> exactly
> > what would be useful. XP chooses the latter approach.
>
> before you still need to wait? Why is it you can't reuse that
> experience immediately on a new project? In fact, it's that
> experience that should guide what people are doing, not vice
> verse. We don't let new mountain climbers pick a route up
> the mountain.
That experience certainly *should* guide you. However, there's no reason to
commit yourself to a framework before you are sure you need it. Once you
know you need it, your experience will help you build it. There is no
substitute for experience, but there is also no substitute for empirical
feedback.
> I'm very interested to know where this line of reasoning stops.
Waiting till you *know* you need something; and knowing how to build what
you need are not mutually exclusive concepts. It is possible to wait until
you know you need what you know how to build.
> Because you will draw a line somewhere. Your line of tossing
> great dump trucks full of experience away on each new project
> does not make any sense at all to me.
I'm not recommending that even the tiniest bit of experience be thrown away.
I'm recommending that experience not be invoked prematurely.
>
> You may say this is sillyness and these are obviously
> different than the other parts of a project, but i don't see
> a difference at all. Or you might say if we really felt it necessary
> you really would create a new language etc, but i wouldn't believe
> this for a second. Given your logic for the database framework you must
> start from scratch in almost all areas because you won't know what
> you really need until you start. A database framework or a dozen
> other common project artifacts are no different.
Will you need transactions? Or will you need record locking? Will you need
multi-threaded access, or will you invent a serialization bottleneck? Will
you create caches, or will you depend upon the underlying system to cache
for you? Etc, etc, etc. How will you keep from building more than you
need? How will you know precisely which features you need? What is the
cost of waiting to build a feature until you know for sure it is needed?
>
> On many products the lights are never turned off. New bulbs
> are constantly beeing added, replaced, moved, and going
> on maternity leave. The turn out the lights notion
> is one a consultant may have, but it doesn't work for ongoing
> concern.
In which case the knowledge of the system remains live in the minds of the
developers.
Phlip
>
> <todd...@my-deja.com> wrote:
> > Even though you probably have written a DB framework 5 times
> > before you still need to wait? Why is it you can't reuse that
> > experience immediately on a new project? In fact, it's that
> > experience that should guide what people are doing, not vice
> > verse. We don't let new mountain climbers pick a route up
> > the mountain.
>
> That experience certainly *should* guide you. However, there's no reason
to
> commit yourself to a framework before you are sure you need it. Once you
> know you need it, your experience will help you build it. There is no
> substitute for experience, but there is also no substitute for empirical
> feedback.
Generals always prepare again to fight their last battle.
Don't do that. (Look at the "Cold" War!)
univ...@saltmine.radix.net
> I'm no longer afraid of waiting to build framework as I need it.
> That's a technical problem and an easy way to work. I'm afraid of not
> delivering real value to my customer ASAP.
From the sw engineering literature, most sw engineers of reknown find that
they develop faster, easier and cheaper with pre-built frameworks. That
is frameworks built prior to the current project based upon experience
with projects with similar requirements: both domain wise and or
technically.
> That's why I do things the way I do.
Elliott
todd...@my-deja.com
"Robert C. Martin" <rma...@objectmentor.com> wrote:
>
> <todd...@my-deja.com> wrote in message
news:8a8fvr$k3k$1...@nnrp1.deja.com...
> > Because you will draw a line somewhere. Your line of tossing
> > great dump trucks full of experience away on each new project
> > does not make any sense at all to me.
>
> I'm not recommending that even the tiniest bit of experience be
thrown away.
> I'm recommending that experience not be invoked prematurely.
You did not respond to the rest of my question asking why languages,
libraries, etc are not included in this list of the possibly
premature. For some reason thinking about databases is premature,
but the rest isn't? You should not have a string class in your
toolbox because you may never need it. And if it turns out you
need it you may a need a different one. In your processor you
may need only fetch instructions so you shouldn't even create the
rest. The reasoning is exactly the same.
> Will you need transactions? Or will you need record locking? Will
you need
> multi-threaded access, or will you invent a serialization
bottleneck? Will
> you create caches, or will you depend upon the underlying system to
cache
> for you?
It's all quite encapsulatable. As are most services, once you
gain experience in the domain.
>How will you know precisely which features you need?
Encapsulate well and these can be changed as needed.
This is not theoretical discussion. We do this all the time.
There's no secret.
> In which case the knowledge of the system remains live in the minds
>of the developers.
That's comforting.
Robert C. Martin
<todd...@my-deja.com> wrote in message news:8ab4u2$imr$1...@nnrp1.deja.com...
> In article <sci1gkg...@news.supernews.com>,
> "Robert C. Martin" <rma...@objectmentor.com> wrote:
> >
> > <todd...@my-deja.com> wrote in message
> news:8a8fvr$k3k$1...@nnrp1.deja.com...
>
> > > Because you will draw a line somewhere. Your line of tossing
> > > great dump trucks full of experience away on each new project
> > > does not make any sense at all to me.
> >
> > I'm not recommending that even the tiniest bit of experience be
> thrown away.
> > I'm recommending that experience not be invoked prematurely.
>
> You did not respond to the rest of my question asking why languages,
> libraries, etc are not included in this list of the possibly
> premature. For some reason thinking about databases is premature,
> but the rest isn't?
We must be talking at cross purposes. I think it's clear that thinking
about writing a new database framework may be premature. Using an existing
database framework may be the simplest thing to do.
Robert C. Martin
>
> Robert C. Martin wrote in message ...
> >You have two options here. Design the DB framework and hope that people
> >find it useful; or wait until people start using the DB and find out
> exactly
> >what would be useful. XP chooses the latter approach.
> >
> This is a real problem for me. Experience tells me that you
> have to write MUCH more code when you don't have a standard
> framework. Hence the (and I'm talking small and simple here)
> framework reduces the work load.
Absolutely true. The question is not whether to write a framework or not.
The question is when you write the framework. Do you write the framework
before any of the code that uses it? Or do you write the framework after
some small part of the code that could use it has been written; and then
rewrite that code. I think the latter is often the more viable approach. I
have been very badly bitten by the former. (See "A Case Study of Reuse and
OOD in C++" in the publications section of http://www.objectmentor.com)
> >> It's hardly speculative to say "we need a read write add and
> >> delete mechanism".
> >
> >Are there any aspects of the API that *are* speculative?
> >
> There's a line where it gets just plain silly to define something
> as speculative. Other's comments about only *ever* doing
> what the customer asks for sometimes cross this line,
> eg the customer doesn't want any security
> so you don't put it in. The auditors then don't allow you
> to go into production.
By customer, we mean the person reponsible for defining requirements. Whose
job is it that the requirements satisfy the auditors? Is it the 'customer'
or the programmers? XP says it is the customer who must define the
requirements and the programmers that must implement them.
> The customer is happy working
> with UAT as Production so you do it but Sys Admin
> use UAT for other stuff on the weekends and power
> off the server without restarting your system.
> You lose data and the user hates you (or at least IT in
> general). I've lived through this one.
Yeah, I've lived though similar stuff too. Developers have the right to
describe these kinds of scenarios to the customers; but it is the customer's
right to accept it as a problem and prioritize it. If the customer gives it
a low priority, you don't do it.
Phlip
> Absolutely true. The question is not whether to write a framework or
not.
> The question is when you write the framework. Do you write the
framework
> before any of the code that uses it? Or do you write the framework
after
> some small part of the code that could use it has been written; and
then
> rewrite that code. I think the latter is often the more viable
approach.
Write the framework after you have some working functionality in the
client code spike that can migrate up into the framework.
--
Phlip
======= http://users.deltanet.com/~tegan/home.html =======
Ell
#
#Nick Thurn <nick....@db.com> wrote in message
#news:8a9c6t$qio$1...@kilmer.bain.oz.au...
#>
#> Robert C. Martin wrote in message ...
#
#> >You have two options here. Design the DB framework and hope that people
#> >find it useful; or wait until people start using the DB and find out
#> exactly
#> >what would be useful. XP chooses the latter approach.
#> >
#> This is a real problem for me. Experience tells me that you
#> have to write MUCH more code when you don't have a standard
#> framework. Hence the (and I'm talking small and simple here)
#> framework reduces the work load.
#
#Absolutely true. The question is not whether to write a framework or not.
#The question is when you write the framework. Do you write the framework
#before any of the code that uses it? Or do you write the framework after
#some small part of the code that could use it has been written; and then
#rewrite that code.
But then you already have a framework for future similar projects.
#I think the latter is often the more viable approach. I
#have been very badly bitten by the former.
So what do you do throw away a framework from a similar, past project and then
recode the framework for each similar, future one?
The above 2 points show the falsity of always waiting to use a framework. It
makes no sense for similar projects. So RCM's formulation for when to use a
framework should be modified to take into account similar projects. His
formulation is in error by assuming that every project is radically different
from another one.
Elliott
Ell
#"Robert C. Martin" <rma...@objectmentor.com> wrote:
##Nick Thurn <nick....@db.com> wrote in message
##> Robert C. Martin wrote in message ...
##> >You have two options here. Design the DB framework and hope that people
##> >find it useful; or wait until people start using the DB and find out
##> exactly what would be useful. XP chooses the latter approach.
##> This is a real problem for me. Experience tells me that you
##> have to write MUCH more code when you don't have a standard
##> framework. Hence the (and I'm talking small and simple here)
##> framework reduces the work load.
##Absolutely true. The question is not whether to write a framework or not.
##The question is when you write the framework. Do you write the framework
##before any of the code that uses it? Or do you write the framework after
##some small part of the code that could use it has been written; and then
##rewrite that code.
#But then you already have a framework for future similar projects.
##I think the latter is often the more viable approach. I
##have been very badly bitten by the former.
#So what do you do throw away a framework from a similar, past project and then
#recode the framework for each similar, future one?
#
#The above 2 points show the falsity of always waiting to use a framework. It
#makes no sense for similar projects. So RCM's formulation for when to use a
#framework should be modified to take into account similar projects. His
#formulation is in error by assuming that every project is radically different
#from another one.
#
#Elliott
The same applies to RJeffries formulation wrt frameworks.
Elliott
Ell
> In which case the knowledge of the system remains live in the minds
>of the developers.
Are there so many in awe of RCM, or ignorant of proper system design
engineering that, there are so few who are willing to forthrightly lay out
just how amateurish the above approach is for archiving, at the very least,
the overall structure of a system's design/architecture?
Elliott
Patrick D. Logan
Ell wrote:
>
> ...ignorant of proper system design...
As we used to say when I was young, "There's more than one way to skin
a cat." The SPCA may get after me for saying that these days.
--
Patrick Logan
patric...@home.com
Ronald E Jeffries
>#The above 2 points show the falsity of always waiting to use a framework. It
>#makes no sense for similar projects. So RCM's formulation for when to use a
>#framework should be modified to take into account similar projects. His
>#formulation is in error by assuming that every project is radically different
>#from another one.
>#
>#Elliott
>
>The same applies to RJeffries formulation wrt frameworks.
What Elliott is unable to notice is that the discussion was about how
to WRITE frameworks. Frameworks, when created, should, in our opinion,
be created by abstracting from actual applications, not by imagining
what might make a good framework and writing it, then trying it out.
Proceeding with framework _development_ in this way ensures that the
interfaces are easy to use, and focuses attention on framework
features of high value before those of lesser value.
If you _have_ a framework for what you're doing already, you should of
course give due consideration to using it. There are times when using
it might not be appropriate, but if it was built in a context of use,
it's likely to be useful again.
Universe
#On Sat, 11 Mar 2000 01:27:21 GMT, univ...@radix.net (Ell) wrote:
#>#The above 2 points show the falsity of always waiting to use a framework. It
#>#makes no sense for similar projects. So RCM's formulation for when to use a
#>#framework should be modified to take into account similar projects. His
#>#formulation is in error by assuming that every project is radically different
#>#from another one. [The same applies to RJeffries formulation wrt frameworks.]
#What Elliott is unable to notice is that the discussion was about how
#to WRITE frameworks.
? That is _precisely_ what I was addressing. I'm saying we generally don't
need a new framework per project, as you say, and RCM wavers in and out of
saying. Frameworks from past similar projects often may serve current
projects. And to fail to do so when applicable is wasteful, and inefficient.
Elliott
Phlip
Amazing. Assuming you have not kill-filed me, here's what Ron just got thru
saying to you.
Ron wrought:
> If you _have_ a framework for what you're doing already, you should of
> course give due consideration to using it. There are times when using
> it might not be appropriate, but if it was built in a context of use,
> it's likely to be useful again.
So you snip the part where he approaches the BuyDontBuild side, and then you
accuse him of saying one must always bake a new framework from scratch.
Incredible.
Do you, like, do these permutations consciously? Or does the urge to flame
rise up in you only half way thru a post, so you don't actually read the
second half?
Eric Langjahr
what they are speaking or writing about as clearly biased by their
interest.
I am not saying that the points of view expressed on XP by some in
this newsgroup are not 100% geniune. Just noting that some of them
have a financial interest in XP since they are offering courses and
training in XP.
Obviously, they would suggest that their statements should be
evaluated on their merit and NOT their motive. But following the
money is often a quicker way to get a true picture<g>.
Fact is, that given almost any topic in software engineering, you can
make lots of arguments, for and against, that will 'sound good'.
Marketing and book writing are about 'sounding good'. In our society
writing a book (or being a high profile celebrity) confers 'expert'
status.
Sometimes what is actually correct doesn't sound good.
It is not always easy to correctly evaluate ideas on their merit.
Often it can take years before a conclusion about an idea can be
reached.
One thing is clear.
As a business owner I do NOT want the knowledge about mission critical
systems to reside in the minds of the developers. As a developer,
providing my role is to deliver a working product and leave, I don't
really care. The business owner and the developers do not, in most
cases, have completely overlapping concerns.
Phlip
> I am not saying that the points of view expressed on XP by some in
> this newsgroup are not 100% geniune. Just noting that some of them
> have a financial interest in XP since they are offering courses and
> training in XP.
I have a financial interest in XP - it's teaching me to slam-dunk project
after lucrative project.
> As a business owner I do NOT want the knowledge about mission critical
> systems to reside in the minds of the developers. As a developer,
> providing my role is to deliver a working product and leave, I don't
> really care. The business owner and the developers do not, in most
> cases, have completely overlapping concerns.
So letting it reside in the source code is not enough?
We've all seen terse convoluted monkey-code efforts - many the result of
BigDesignUpFront followed by wheel reinvention frenzies. Such code is
unreadable & fragile, so it needs lots of documentation. But is it possible
you never saw the alternative? Clean, easy to read, easy to change code that
keeps none of its design a secret?
Would you tell your coders to budget 25% of their time documenting bad code?
or 25% of their time cleaning it up?
BTW you can download apps that eat a bunch of source and create UML diagrams
from it for free on the 'net.
Oil the machine, holmes!
Jason Che-han Yip
<snip>
> As a business owner I do NOT want the knowledge about mission critical
> systems to reside in the minds of the developers. As a developer,
I think you meant "to *only* reside in the minds of the developers". I'm sure
you don't mean that you don't want your developers to have no knowledge about
what they are developing. I'm sure there was a Dilbert comic about this...
--
Graduate Student, SE Lab, University of Calgary,
http://www.sern.enel.ucalgary.ca/yip
----
XP2000 - June 21-23, 2000
eXtreme Programming and Flexible Processes in Software Engineering
http://www.spe.ucalgary.ca/extreme
Patrick D. Logan
Eric Langjahr wrote:
>
> Obviously, they would suggest that their statements should be
> evaluated on their merit and NOT their motive. But following the
> money is often a quicker way to get a true picture<g>.
Wouldn't also assume anyone selling training for a few thousand
dollars has a stake in the students being successful? If they are
selling snake oil, they aren't going to get very wealthy. Or do you
assume they'll sell XP until we all wise up, then they'll sell us
something else? I think these guys have been around demonstrating
success for too long to infer they are charlatans.
> Fact is, that given almost any topic in software engineering, you
> can make lots of arguments, for and against, that will 'sound
> good'.
Exactly. XP has to actually lead to success.
> As a business owner I do NOT want the knowledge about mission
> critical systems to reside in the minds of the developers.
Hmm. What *do* you want to reside in the minds of the developers?
--
Patrick Logan
patric...@home.com
Universe
#Ell wrote:
#> ...ignorant of proper system design...
#As we used to say when I was young, "There's more than one way to skin
#a cat." The SPCA may get after me for saying that these days.
There are practices and issues which are common to at least 85 if not 95% of
all systems created by using good engineering principles--no matter what the
field. These issues and practices constitute "proper" system design. One of
those practices is documenting system design and theory of operation for
future operators and maintainers of the system. It is even necessary to
coordinate a current large, and or distributed development effort. This is
spoken about in various system engineering books, both general and specific.
Other than by XP'ers, please show me engineering books and texts that advocate
doing otherwise than what I advocate above.
Elliott
Ronald E Jeffries
<lang...@itsdata.com> wrote:
>One thing is clear.
>
>As a business owner I do NOT want the knowledge about mission critical
>systems to reside in the minds of the developers. As a developer,
>providing my role is to deliver a working product and leave, I don't
>really care. The business owner and the developers do not, in most
>cases, have completely overlapping concerns.
Probably you mean, Eric, that you don't want that knowledge residing
SOLELY in their minds. You'll find it useful if the developers do have
that knowledge in their heads, I expect.
The more knowledge the developers have in their heads, the faster
they'll go. Various communications approaches will help with that, and
the more "intimate" the communication, the more effective it will be,
especially with smaller numbers of developers. (I'd not suggest
word-of-mouth communication for a 100-person project.)
Then, as project manager or business owner, you can specify whatever
documentation you want written for business purposes. Your costs are
optimized when there are no documents needed by the developers that
you don't also want for business purposes.
Ron Jeffries
http://www.XProgramming.com
Ronald E Jeffries
>? That is _precisely_ what I was addressing. I'm saying we generally don't
>need a new framework per project, as you say, and RCM wavers in and out of
>saying. Frameworks from past similar projects often may serve current
>projects. And to fail to do so when applicable is wasteful, and inefficient.
Don't misquote me. I have never said that we need a new framework per
project, and I specifically said the opposite in the posting to which
you are responding.
Ron Jeffries
http://www.XProgramming.com
topmind
<patric...@home.com> wrote:
>
>
>Eric Langjahr wrote:
>>
>> Obviously, they would suggest that their statements should be
>> evaluated on their merit and NOT their motive. But following
the
>> money is often a quicker way to get a true picture<g>.
>
>Wouldn't also assume anyone selling training for a few thousand
>dollars has a stake in the students being successful? If they
are
>selling snake oil, they aren't going to get very wealthy. Or do
you
>assume they'll sell XP until we all wise up, then they'll sell
us
>something else? I think these guys have been around
demonstrating
>success for too long to infer they are charlatans.
>
>> Fact is, that given almost any topic in software engineering,
you
>> can make lots of arguments, for and against, that will 'sound
>> good'.
>
>Exactly. XP has to actually lead to success.
>
>> critical systems to reside in the minds of the developers.
>
developers?
>
These sales-versus-merit arguments remind me of battles about
Microsoft NT.
Many technicians think NT is crap and can't understand why NT
still sells. They often attribute it to MS's clever, pushy, and
well-funded marketing.
IMO, there is too much selling based on overly-general concepts
and talk and not enough objective research in most of IT.
I.T. is mostly an art, and very little real science these days.
Perhaps it would slow progress to wait until studies are
finished. However, the current approach should not be called
"science" regardless of whether it is the most effective or not.
>--
>Patrick Logan
>patric...@home.com
>
>
-tmind-
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
Patrick D. Logan
Universe wrote:
>
> There are practices and issues which are common to at least 85 if
> not 95% of all systems created by using good engineering principles
> --no matter what the field. These issues and practices constitute
> "proper" system design.
And in new disciplines like programming, tools change and ideas
change to fit the new tools. This is called "innovation". If
everything was always done "properly" there would never be any
innovation!
> One of those practices is documenting system design...
There are people today innovating new ways of documentation. They
may not be "proper" according to your definition. If you do not
want to follow their advice, or want to wait until there is more
experience with it, fine. It is OK not to be an innovator. It
probably would not be good for 85-95 percent of developers to
be innovating all at once. But it *is* a good thing to have 10
percent of developers trying something new to see if it works
better.
> Other than by XP'ers, please show me engineering books and texts
> that advocate doing otherwise than what I advocate above.
I am not saying that traditional processes are complete failures.
But I think you are jumping the gun to be so quick to want to
stifle the innovators who may have found something better for
some, possibly many, maybe even most, circumstances.
I am sure a self-proclaimed progressive liberal such as yourself
agrees that there is a need for innovation and open mindedness;
that conservatism should not *always* be the rule.
--
Patrick Logan
patric...@home.com
Patrick D. Logan
topmind wrote:
>
> I.T. is mostly an art, and very little real science these days.
> Perhaps it would slow progress to wait until studies are
> finished. However, the current approach should not be called
> "science" regardless of whether it is the most effective or not.
I think most of the people you have been in communication with in this
newsgroup would agree. And I think they would tell you they are
presenting information they have gathered from real experience. While
this experience is not "science" it is evidence and not snake oil.
--
Patrick Logan
patric...@home.com
Eric Langjahr
crap. You can be ISO 9000, be CMM level X, or any other technique (or
no technique) and still produce crap.
My solution to this is simple. I won't work on this type of project.
In fact I will not work on any project that involves more than 4-5
developers. I just think after that it is NOT fun. And generally not
the kind of software I want to be involved in. I'll leave the space
shuttle and defense industy work to others<g>
Most often I work alone. My process is closer to XP than anything
else.
I don't think there IS a formula for producing software that is
correct, robust, extendible and reusable. Anymore than there is a
formula for producing a box office success. Many have studied how
Hitchcock made movies. Still there are few Hitchcocks.
And I really don't think there is any way to teach most developers to
write code that is simple, clear, and readible. They either have it
or they don't.
But we try to find the secret because we do know that some people seem
to produce good software and can repeat it over and over again and
others cannot.
I do think that giiven some reasonable High level documentation, a
developer can get a far QUICKER understanding of what is going on than
from just looking at code. I don't think that XP really produces this
type of documentation although I also realize that there is nothing in
XP that says it can't
And, of course, it DEPENDS on the code and the tools you are using
too! I think that the Eiffel idea (along with DBC) of letting the
code also be documenting is a very good one and that is and will
continue to be a fertile area for research.
I think that diagramming tools like BON are far superior to UML which
is overly complex. The attempt to have UML be a language which can
generate code may be misguided. It will never be as efficient as
simply coding. There will always be constructs that don't easily
mate to UML as languages evolve (yeah I know it is extensible). And
what is the advantage to coding in UML versus coding in C++,
smalltalk, or X? I don't think there is one. If the industries goal
is to cater to the 80%(at least) that are inept perhaps it is a good
idea. We can bring everyone down to their level. But if the goal is
to produce tools that do not get in the way of the truly competent in
producing excellent software the UM LANGUAGE cannot be the right idea.
May 99 Computer had an interview with Ken Thompson. Makes interesting
reading. He certainly recognizes the experimental / exploratory
nature of programming.
I agree with many XP'ers who say that the code is more what the system
is than anything else.
I have doubts about pair programming. But I have had very good
success with pair debugging<g>. So I have an open mind about it.
I also think that XP is more suited to some tools than to others. It
can't be lost on many that the refactoring and XP community has many
Smalltalk programmers. That is because Smalltalk has great
refactoring tools, and is in general, one of the best, IMO,
environments to program in.
I think the Smalltalk community has produced many of the great ideas
in the OO community. All the most common patterns (even before we
called them that) came from Smalltalk programmers.
Having said that I think that much could be done to make Smalltalk
better but doubt whether it will get the attention it deserves.
But the thrust of my original comments was not whether XP was good or
bad or whether another methodology or process was better. Just that
when someone who was selling training in BDUF and UML (or some
variant) three years ago is now selling something that most would say
is quite a bit different it could represent one of two things (or a
combination thereof):
a) Religous conversion
b) Financial interest
The fact remains that IT is a very fad driven industry. For those
selling tools and seminars it is FAR more profitable to be selling a
new thing than continuing to sell the old one. Especially after the
old one has reached some level of market penetration.
That doesn't make the old thing bad or the new thing bad. It is
simply a fact.
That is why many Smalltalk vendors (and others too) jumped on the Java
bandwagon. I posted on comp.lang.smalltalk that I thought that
ObjectShare was making a HUGE mistake in this regard in late 96 or 97
(just after VSE was dropped). Revenue streams from product upgrades
and support just can't support most software businesses long term
(especially development tools). NEW products are what make the bulk
of the money. You can only sell but so many UML seminars to the same
group of people. But come up with a new idea, say XP, and you can
resell to many of the same people again.
The tools based part, I think, can only be solved by the
Superdistribution concepts that Brad Cox writes about. Unfortunately
many issues remain with this.
The seminar issue is not unique to IT. But we are a very faddish
industry. I remember when IMS was all the rage. Then it was
relational. Ironically the IMS network model of DB is a better match
for OO concepts than the relational one. But in the late 70's if you
wanted a database job on mainframes, IMS was big.
Then it was DB2.
Well were we wrong about network database model? Right about
relational model? Or are both just part of the new, better, different
syndrome that IT has?
Although I like raising issues it was not my intent to flame anybody
in particular.
I read Robert Martins last book and look forward to the promised
update. I enjoy (and have benefited) from his posts on c.o and
elsewhere. I do think that alot of what he has stressed is very C++
specific. For instance his treatment of dependency issues.
I think Kent Becks had done some marvelous books and columns on
Smalltalk and patterns. I continue to have an open mind about XP
My comments were more on the industry in general.
On 11 Mar 2000 13:28:12 EST, "Phlip" <x@x.x> wrote:
>Eric Langjahr wrote:
>
>> I am not saying that the points of view expressed on XP by some in
>> this newsgroup are not 100% geniune. Just noting that some of them
>> have a financial interest in XP since they are offering courses and
>> training in XP.
>
>I have a financial interest in XP - it's teaching me to slam-dunk project
>after lucrative project.
>
>> As a business owner I do NOT want the knowledge about mission critical
>> systems to reside in the minds of the developers. As a developer,
>> providing my role is to deliver a working product and leave, I don't
>> really care. The business owner and the developers do not, in most
>> cases, have completely overlapping concerns.
>
Eric Langjahr
>
>Eric Langjahr wrote:
>>
>> Obviously, they would suggest that their statements should be
>> evaluated on their merit and NOT their motive. But following the
>> money is often a quicker way to get a true picture<g>.
>
>Wouldn't also assume anyone selling training for a few thousand
>dollars has a stake in the students being successful? If they are
>selling snake oil, they aren't going to get very wealthy. Or do you
>assume they'll sell XP until we all wise up, then they'll sell us
>something else? I think these guys have been around demonstrating
>success for too long to infer they are charlatans.
>
hired them for anything. Yes I do tend to think in our industy its
more of the sell them something until they wise up and then sell them
something else.
As I mention in another post though I was not really
targeting any people in particular or XP more than anything else. It
was more in the nature of observations about our industry
>
>> Fact is, that given almost any topic in software engineering, you
>> can make lots of arguments, for and against, that will 'sound
>> good'.
>
>Exactly. XP has to actually lead to success.
>
>> As a business owner I do NOT want the knowledge about mission
>> critical systems to reside in the minds of the developers.
>
>Hmm. What *do* you want to reside in the minds of the developers?
Obviously I meant SOLELY in their minds.
todd...@my-deja.com
> newsgroup would agree. And I think they would tell you they are
> presenting information they have gathered from real experience. While
> this experience is not "science" it is evidence and not snake oil.
What's interesting is if you say that creating frameworks has worked
in your projects many many many times, that this is solid
profitable experience, it is completely discounted by XPers.
There is no room in XP for any other position on frameworks, which
i find irrational, given they rely heavily on "experience" in
their supporting arguments. It gives XP a religious vibe, as do
posts where a someone writes "XP says xyz."
Eric Langjahr
>>selling snake oil, they aren't going to get very wealthy. Or do you
>>assume they'll sell XP until we all wise up, then they'll sell us
>>something else?
You don't think that model can work?
Look at Republicans and Democrats. They are virtually the same
exact thing. Their only interest is in keeping government large. The
more control government has over our lives, the more desireable it is
for special interests to buy government. They push campaign finance
'reform'. In REALITY the only viable 'reform' is to reduce the
CONTROL government has over our lives.
The reality is that there is not one DIMES worth of difference
between a Republican or Democrat. Sure they want to 'beat' each
other. But their overriding interest is in seeing that the game
doesn't change and that they are the only players in the game.
They create the problems and then tell you that without their help
you won't be able to fix them.
So yes. Every four years (in the case of the Presidential
politics) they drag out the same TIRED solutions. And evey four years
most of my fellow Americans say HEY, that sounds pretty good<g>.
Patrick D. Logan
Eric Langjahr wrote:
>
> I read Robert Martins last book and look forward to the promised
> update. I enjoy (and have benefited) from his posts on c.o and
> elsewhere. I do think that alot of what he has stressed is very C++
> specific. For instance his treatment of dependency issues.
A large part of it also applies to Java. Many of the general ideas
also apply to Smalltalk. I recommend the book even to Smalltalk
programmers if for no other reason than to serve as an example of
someone thinking through a design clearly in *any* language. The
dynamic nature of Smalltalk is not a license to throw caution to
the wind.
--
Patrick Logan
patric...@home.com
Phlip
> ...It gives XP a religious vibe, as do
> posts where a someone writes "XP says xyz."
When an XP initiate reads such a post, what goes in their brain is "XP guru
Frank N. Furter says xyz, and it probably works because it fit with all the
other principles that I've already seen working on my own XP projects."
When a non-initiate reads such a post, what goes in their brain is "XP guru
Frank N. Furter says xyz, and it's probably dogma because it demands blind
obedience and uses strange words."
Frank directed a post at the XP initiates, after they are over the learning
curve. When a non-initiate reads this they are put off. When an initiate
reads it they fit it in with what they already know, no blind obedience
required.
Phlip
Eric Langjahr wrote:
> I do think that giiven some reasonable High level documentation, a
> developer can get a far QUICKER understanding of what is going on than
> from just looking at code. I don't think that XP really produces this
> type of documentation although I also realize that there is nothing in
> XP that says it can't
<eXtreme dogma mode>
Yes there is: They can't. The "eXtreme" in XP means the 12 Commandments are
performed extremely, with no time (in a 40-hour week) for any baloney.
</eXtreme dogma mode>
Beyond this extremity, if you are the customer you may request a design
document. Getting one _after_ a team finishes is better than when one
starts. That's a good way to ice an XP project (unless everyone on the XP
team got killed in a plane crash or something).
--
Phlip
======= http://users.deltanet.com/~tegan/home.html =======
-- Fatal Error C4101: Attention span exceeded. --
Eric Langjahr
I can't assume that a developer (or even all the developers) who were
involved in a project will be around 1 year from now. (Personally
after a year I am usually bored<g>)
So from a business point of view some documents that will help
developers get up to speed are helpful.
And while the plane crash scenario Phillip mentioned is unlikely it
is, nonetheless, an interesting one.
If most documentation is deferred till the end what happens if the key
people most able to do it, leave, quit, or die in a plane crash?
What happens on an XP team with four programmers where the two most
senior leave to start their own business and the team is left with two
junior programmers?
Am I worse or better off if I have some up front design documents that
reflect where they were going? Or not?
How would you feel if your money were on the line?
On Sun, 12 Mar 2000 03:52:44 GMT, "Patrick D. Logan"
<patric...@home.com> wrote:
>
>
>Eric Langjahr wrote:
>>
>> I do think that given some reasonable High level documentation, a
>> developer can get a far QUICKER understanding of what is going on
>> than from just looking at code.
>
>You are talking about someone coming in cold on a system and learning
>by themselves.
>
>XP's approach is talking about people working together on all parts
>of the system.
>
>So you see this is an apples vs. oranges comparison.
>
>> I don't think that XP really produces
>> this type of documentation although I also realize that there is
>> nothing in XP that says it can't
>
>Some XP people have suggested that if this kind of documentation is
>desired then it should be a scheduled task prioritized by the
>paying customer.
Patrick D. Logan
Eric Langjahr wrote:
>
> I can't speak as to their success or failure having never
> hired them for anything. Yes I do tend to think in our industy its
> more of the sell them something until they wise up and then sell them
> something else.
That may be true of some "personalities" in the industry, it is
definitely not my experience of these guys, who've been working on
XP-like ideas for the ten years I've been exposed to them.
> As I mention in another post though I was not really
> targeting any people in particular or XP more than anything else. It
> was more in the nature of observations about our industry
I agree with you in general and can vouch for XP as being the exception
rather than the rule.
--
Patrick Logan
patric...@home.com
Patrick D. Logan
Eric Langjahr wrote:
>
> >> If they are selling
> >>snake oil, they aren't going to get very wealthy. Or do you
> >>assume they'll sell XP until we all wise up, then they'll sell us
> >>something else?
>
> You don't think that model can work?
I know of people who follow that model. If I didn't know better, I
might assume the XP people are the same way. But I've been reading
their writings for a long time, I've met some of them, and know a
couple of them fairly well. In this case I know it is not the model.
They are basing XP on real experience.
The question will be how well does it transfer over to the people
interested in adopting it.
> Every four years (in the case of the Presidential
> politics) they drag out the same TIRED solutions. And evey four
> years most of my fellow Americans say HEY, that sounds pretty
> good<g>.
Fortunately software development might not be so entrenched as
American politics. The XP people strike me as innovators rather
than politicians. (Maybe that's not a good sign for success in
selling XP. Maybe XP needs a good politician or two.)
--
Patrick Logan
patric...@home.com
Patrick D. Logan
todd...@my-deja.com wrote:
>
> What's interesting is if you say that creating frameworks has worked
> in your projects many many many times, that this is solid
> profitable experience, it is completely discounted by XPers.
> There is no room in XP for any other position on frameworks, which
> i find irrational, given they rely heavily on "experience" in
> their supporting arguments.
XP promotes building frameworks just as people like Ralph Johnson have
been suggesting for years: you build two or three applications and
derive the framework from their experience as well as code.
> It gives XP a religious vibe, as do posts where a someone writes
> "XP says xyz."
This is something that XP promoters will have to watch out
for. XP will have to be promoted in terms programmers are familiar with
*without* redefining those terms. I think the term "extreme" itself is
too extreme. I would not want to change the content of XP, but see it
promoted more "comfortably", e.g. as a kind of RUP process.
--
Patrick Logan
patric...@home.com
Universe
#It gives XP a religious vibe, as do posts where a someone writes "XP says xyz."
Religion means believing based upon faith. How is "XP says xyz" believing
based upon faith? Is it not invalid to say "XP says xyz"? Finally, what
makes your "XP says xyz" any better than anyone else's?
Elliott
Universe
#too extreme. I would not want to change the content of XP, but see it
#promoted more "comfortably", e.g. as a kind of RUP process.
But the essence of RUP is architecture centered, use case led development. XP
strikes out on both counts.
Elliott
Universe
#On Sat, 11 Mar 2000 13:26:54 GMT, univ...@radix.net (Universe) wrote:
#
#>? That is _precisely_ what I was addressing. I'm saying we generally don't
#>need a new framework per project, as you say, and RCM wavers in and out of
#>saying. Frameworks from past similar projects often may serve current
#>projects. And to fail to do so when applicable is wasteful, and inefficient.
#Don't misquote me. I have never said that we need a new framework per
#project, and I specifically said the opposite in the posting to which
#you are responding.
The thing is you XP'ers so emphasize the fact that frameworks should be based
upon specific project experience that it just like advocating a new framework
per project. Both you and RCM only talked about reusing frameworks across
similar projects after the logic for doing so was brought to your attention.
Prior to that it was develop a framework only after having done a fair amount
of work in the project.
Elliott
Patrick D. Logan
Eric Langjahr wrote:
>
> I do think that given some reasonable High level documentation, a
> developer can get a far QUICKER understanding of what is going on
> than from just looking at code.
You are talking about someone coming in cold on a system and learning
by themselves.
XP's approach is talking about people working together on all parts
of the system.
So you see this is an apples vs. oranges comparison.
> I don't think that XP really produces
> this type of documentation although I also realize that there is
> nothing in XP that says it can't
Some XP people have suggested that if this kind of documentation is
desired then it should be a scheduled task prioritized by the
paying customer.
--
Patrick Logan
patric...@home.com
Patrick D. Logan
What you say about XP is not true. XP is led by "user stories", i.e.
use cases that the customer is in charge of. And the goal of XP is
to develop the best architecture for the customer-chosen use cases
with the least amount of effort.
--
Patrick Logan
patric...@home.com
Patrick D. Logan
Eric Langjahr wrote:
>
> I can't assume that a developer (or even all the developers) who were
> involved in a project will be around 1 year from now. (Personally
> after a year I am usually bored<g>)
(1) What makes you bored after one year?
(2) What ration of developers will still be around? What ratio of
senior people? Junior?
Depending on the characteristics of turnover, maybe XP would be a
good way to support your turnover (or perhaps make the culture more
appealing to reduce the turnover.)
> So from a business point of view some documents that will help
> developers get up to speed are helpful.
If you really have a lot of people coming in cold without the
assistance of co-workers then perhaps you want to change that instead
of trying to smooth it over?
> And while the plane crash scenario Phillip mentioned is unlikely it
> is, nonetheless, an interesting one.
Then don't send everyone on the same plane. It's not uncommon to take
these kinds of precautions for VIPs.
> If most documentation is deferred till the end what happens if the key
> people most able to do it, leave, quit, or die in a plane crash?
That's a reason to try to change the culture, and until you have, to
take other precautions like some appropriate amount of "introductory
material".
> What happens on an XP team with four programmers where the two most
> senior leave to start their own business and the team is left with two
> junior programmers?
I am not sure anyone has experienced that on an XP team. I don't feel
qualified to answer, but I can suppose. I suppose:
(1) The exiting developers are willing to provide for a smooth
transition. Given the situation, the highest priority task will
be to bring the junior developers even more up to speed than the
XP process has accomplished to date. Maybe even new developers
will be located in time to work with the exiting developers.
(2) If your crop of developers cannot be trusted to provide for a
smooth transition then you probably want to always pay for the
kind of documentation that will help new people get up to speed.
Personally, I think what you'll need most is a good implementation
that conforms to all the XP design principles. I don't think a ton
of extra documentation outside of the requirements specification
will help. YMMV depending on the kind of applications you build.
> Am I worse or better off if I have some up front design documents that
> reflect where they were going? Or not?
I guess that depends on the meaning of "some" and what it is they are
documenting. I think if you follow XP and have reasonable people
participating you will be in pretty good shape. If not, then not.
> How would you feel if your money were on the line?
I think I'd be happy with XP and reasonable people.
--
Patrick Logan
patric...@home.com
Phlip
> What happens on an XP team with four programmers where the two most
> senior leave to start their own business and the team is left with two
> junior programmers?
You have the salary available for two seniors. Get one, and see what your
new velocity is.
> Am I worse or better off if I have some up front design documents that
> reflect where they were going? Or not?
You are worse off expecting those up-front documents to match the code. Some
20% of that code will need to be morphed 80% away from that up-front
document. At this time your team can either not do the change and suffer, do
the change and make a lie of 20% of the document, or do the change and spend
time upgrading the document.
If your team likes to acrue frequent flyer miles on the same flights for
some strange bonding reason, you'l need to settle for intermittent
documentation, clean code, and some kind of warm-up time for your
replacement team. If anything should happen.
> How would you feel if your money were on the line?
I tire of bosses who think that just because I'm taking the payroll instead
of making it my own money is not on the line. My investment in the project
certainly is on that line, too. And I /like/ writing lots of documents that
describe just how awesome my code is.
Robert C. Martin
Eric Langjahr <lang...@itsdata.com> wrote in message
news:a50lcsots7j1lv0su...@4ax.com...
> Well I take the statements of ANYONE who has a financial interest in
> what they are speaking or writing about as clearly biased by their
> interest.
This is undoubtedly true. I do in fact have a financial interest in XP; and
this necessarily makes my words in support of XP suspect. As such, all
would be well advised to view my posts about XP with a critical eye.
Indeed, all would be well advised to view XP itself with a critical eye. It
has not been tried on nearly enough projects to be considered "proven". On
the other hand, the successes that XP has enjoyed are worth further
investigation IMHO.
> One thing is clear.
>
> As a business owner I do NOT want the knowledge about mission critical
> systems to reside in the minds of the developers.
During development I rather suspect that you ferverently hope that the
knowledge of the system is in the minds of the developers. If you want it
kept elsewhere, you can ask them to create the necessary documents and keep
them up to date. This will be expensive, so you have to judge how often
they should do this. For many systems, creating the documents at the end of
the project may be sufficient.
> As a developer,
> providing my role is to deliver a working product and leave, I don't
> really care. The business owner and the developers do not, in most
> cases, have completely overlapping concerns.
This is the raw essence of XP -- the separation of concerns between business
and development. XP divides the responsibilities such that business makes
all the business decisions, and development makes all the technical
decisions. Business is responsible for defining and prioritizing content.
Development is responsible for estimating and implementing content.
--
Robert C. Martin | "Uncle Bob" | Training Courses:
Object Mentor Inc. | rma...@objectmentor.com | OOD, Patterns, C++, Java,
PO Box 85 | Tel: (800) 338-6716 | Extreme Programming.
Grayslake IL 60030 | Fax: (847) 548-6853 | http://www.objectmentor.com
"One of the great commandments of science is:
'Mistrust arguments from authority.'" -- Carl Sagan
Robert C. Martin
Ell <univ...@radix.net> wrote in message
news:38c99f0e...@news1.radix.net...
> "Robert C. Martin" <rma...@objectmentor.com> wrote:
>
> #
> #Nick Thurn <nick....@db.com> wrote in message
> #news:8a9c6t$qio$1...@kilmer.bain.oz.au...
> #>
> #> Robert C. Martin wrote in message ...
> #
> #> >You have two options here. Design the DB framework and hope that
people
> #> >find it useful; or wait until people start using the DB and find out
> #> exactly
> #> >what would be useful. XP chooses the latter approach.
> #> >
> #> This is a real problem for me. Experience tells me that you
> #> have to write MUCH more code when you don't have a standard
> #> framework. Hence the (and I'm talking small and simple here)
> #> framework reduces the work load.
> #
> #Absolutely true. The question is not whether to write a framework or
not.
> #The question is when you write the framework. Do you write the framework
> #before any of the code that uses it? Or do you write the framework after
> #some small part of the code that could use it has been written; and then
> #rewrite that code.
>
> But then you already have a framework for future similar projects.
>
> #I think the latter is often the more viable approach. I
> #have been very badly bitten by the former.
>
> So what do you do throw away a framework from a similar, past project and
then
> recode the framework for each similar, future one?
That would be silly.
> The above 2 points show the falsity of always waiting to use a framework.
Not waiting to *use*, waiting to *write*. If you've got a framework written
already, by all means use it as much as you can. I wouldn't have thought
that that needed explaining.
Robert C. Martin
> But the thrust of my original comments was not whether XP was good or
> bad or whether another methodology or process was better. Just that
> when someone who was selling training in BDUF and UML (or some
> variant) three years ago is now selling something that most would say
> is quite a bit different it could represent one of two things (or a
> combination thereof):
>
> a) Religous conversion
> b) Financial interest
Object Mentor has never endorsed BDUF, as a careful inspection of our many
publications will show. We have endorsed, and continue to endorse, UML
because it is a useful notation for depicting software designs. When we
came accross XP, it fit so well with our philosophy of software development
that we struck up an alliance with Kent Beck, Martin Folwer, Ron Jeffries
and Ward Cunningham to promote and train XP. This certainly qualifies as a
financial interest.
> The fact remains that IT is a very fad driven industry.
And for the moment, XP is in the "fad" stage. I'm betting it will survive
that stage and enter the mainstream. That bet is based upon my own
successes with lightweight iterative processes. I think XP is the best
description of such a process to come along so far.
> For those
> selling tools and seminars it is FAR more profitable to be selling a
> new thing than continuing to sell the old one. Especially after the
> old one has reached some level of market penetration.
You are wise to be suspicious and critical of commercialization.
Commercialization can destroy many good things. I intend for that not to
happen to XP; but you should read those words critically too. The best
thing anyone can do regarding XP is to try it for themselves.
>
> I read Robert Martins last book and look forward to the promised
> update. I enjoy (and have benefited) from his posts on c.o and
> elsewhere. I do think that alot of what he has stressed is very C++
> specific. For instance his treatment of dependency issues.
Agreed -- to an extend. Dependencies are very strong in C++. They have
fewers symptoms in languages like Java and Smalltalk. But that doesn't mean
they are without harm, or that dependencies in those languages do not need
to be managed.
Robert C. Martin
<todd...@my-deja.com> wrote in message news:8aeknd$vnj$1...@nnrp1.deja.com...
> In article <38CACF4A...@home.com>,
> > newsgroup would agree. And I think they would tell you they are
> > presenting information they have gathered from real experience. While
> > this experience is not "science" it is evidence and not snake oil.
>
> in your projects many many many times, that this is solid
> profitable experience, it is completely discounted by XPers.
Not at all. I agree that you have found it valuable in the past. I too
have found it valuable. It's just that I think the XP approach is a better
way to *make* the frameworks.
> There is no room in XP for any other position on frameworks, which
> i find irrational, given they rely heavily on "experience" in
> their supporting arguments. It gives XP a religious vibe, as do
> posts where a someone writes "XP says xyz."
Yes, it's hard to write about XP without writing things like "XP says...",
or "In XP we...". I understand why you might associate such commentary with
fundementalist writings.
Ronald E Jeffries
><eXtreme dogma mode>
>
>Yes there is: They can't. The "eXtreme" in XP means the 12 Commandments are
>performed extremely, with no time (in a 40-hour week) for any baloney.
>
></eXtreme dogma mode>
Phlip, I feel that you do yourself and the rest of us a disservice
with such comments. There is no XP commandment that says do no
documentation. If an XP team needs a document, they will write it.
I do happen to believe that a small close-knit team needs very few
documents. So I just ask that if they create a document and find it
isn't being used, they stop creating it.
And, as you point out, if the PTB want a document, they just produce a
story card calling for it.
Ron Jeffries
http://www.XProgramming.com
Ronald E Jeffries
<lang...@itsdata.com> wrote:
>What happens on an XP team with four programmers where the two most
>senior leave to start their own business and the team is left with two
>junior programmers?
>
>Am I worse or better off if I have some up front design documents that
>reflect where they were going? Or not?
I'd rather have two junior programmers who have been pairing with the
seniors, and who know the actual code, than any document. I could ask
the programmers questions, have them write documents if I wanted them,
and meanwhile they could maintain the system, which no pile of paper
could do.
That's why XP teams do pair programming, so all the programmers KNOW.
Ron Jeffries
http://www.XProgramming.com
Ronald E Jeffries
<patric...@home.com> wrote:
>(2) What ration of developers will still be around?
It's not nice to eat your fellow programmers. Usually.
Ron Jeffries
http://www.XProgramming.com
Ronald E Jeffries
>The thing is you XP'ers so emphasize the fact that frameworks should be based
>upon specific project experience that it just like advocating a new framework
>per project.
We say that the best way to produce a framework is to build it
simultaneously with one or more applications using it. We do not
believe that frameworks should be built on speculative design, but on
actual use.
That is not the same as saying that you should build a framework for
each application.
>Both you and RCM only talked about reusing frameworks across
>similar projects after the logic for doing so was brought to your attention.
We thought that everyone knew and accepted that frameworks' only
purpose was to be reused, but I do apologize for not mentioning it. By
the way, the sky is blue.
>Prior to that it was develop a framework only after having done a fair amount
>of work in the project.
As you may know, one of my mottos is that logic is overrated as a
system of thought. I see that it is one of yours as well.
We DO say that frameworks are best developed in conjunction with their
use in actual applications.
That does not imply, nor do we intend, that every application needs to
build yet another framework. If you have a suitable framework, you
should use it. To do otherwise would be wasteful.
Thank you for your kind attention.
Ron Jeffries
http://www.XProgramming.com
Ronald E Jeffries
Ronald E Jeffries
<lang...@itsdata.com> wrote:
> I can't speak as to their success or failure having never
>hired them for anything. Yes I do tend to think in our industy its
>more of the sell them something until they wise up and then sell them
>something else.
>
> As I mention in another post though I was not really
>targeting any people in particular or XP more than anything else. It
>was more in the nature of observations about our industry
I'm sorry to see you so cynical at such a young age. ;->
Personally, I believe that most people in our business are trying to
do their best. Frankly, I'd find it very depressing to work in
software if it were otherwise.
There's lots of hype in advertising and selling, yes, but that's not
about software. It says on my Cheerios box:
<small>in a low-fat diet, whole grain foods like</small>
<big>CHEERIOS MAY REDUCE THE RISK OF HEART DISEASE</big>
The fact that the small print completely changes the meaning of the
sentence is typical of advertising everywhere. Most of us just ignore
it and eat the cereal, or use the word processor, because we like it.
All my life, people have hired me and paid me because I manage to get
software done that they like. Maybe I've been lucky, but I've never
been in a company that didn't GET that they needed to satisfy the
customer.
Much of what I've done over the years is to coach people, cajole them,
OK beat them up, to make them better. When I was fortunate enough to
get hooked up with XP, I found that it codified principles and
practices that I believe in, and that it brought a more rounded
collection of practices, making the whole more effective.
I like XP and find it useful. I've chosen to share what I've learned
with those who are interested. I give the best I've got, and yes, I do
get paid for it.
I think most of us here give the best we've got, and that most of us
here do get paid for it. I think that's a good thing.
One last point: I believe that I have gotten zero leads and zero
business from my postings on comp.thisandthat. (Some of you are not
surprised.) I do it because I'm trying to contribute, not because I
think it's effective advertising.
Thanks for being there,
Ron Jeffries
http://www.XProgramming.com
Ronald E Jeffries
<patric...@home.com> wrote:
>Maybe XP needs a good politician or two.
I guess that won't be me ...
Ron Jeffries
Extreme Hammer. You look like a nail to me.
www.XProgramming.com
Universe
#todd...@my-deja.com wrote:
##It gives XP a religious vibe, as do posts where a someone writes "XP says xyz."
#Religion means believing based upon faith. How is "XP says xyz" believing
#based upon faith? Is it not invalid to say "XP says xyz"? Finally, what
#makes your "XP says xyz" any better than anyone else's?
Rather:
#Religion means believing based upon faith. How is "XP says xyz" believing
#based upon faith? Is it not
valid
#to say "XP says xyz"? Finally, what
#makes your "XP says xyz" any better than anyone else's?
Elliott
Phlip
> "Patrick D. Logan" wrote:
>
> >Maybe XP needs a good politician or two.
>
> I guess that won't be me ...
"Only the true messiah denies his divinity." --From the Life of Brian.
Universe
"XP is about Use Case led Architecture" in dream land. Geez, all the XP'ers
says in this regard is that they use a system metaphor and this is hardly
driving development based upon integrating the, 4 + 1 RUP areas, led by the
'+1' area.
The 4 key RUP areas are: logical, process, development, and physical views.
The "+1" is the scenario (use case) view. The scenario view is "+1" because it
is considered to be the primary and unifying view.
Further use case led means all-around investigation of all key use cases as a
whole before the heart of high level production coding. RMartin is clear on
saying once a set of stories is gotten from the client, XP projects can code.
That is not the same as all-around investigation of all key use cases as a
whole before the heart of high level production coding.
Also RMartin's claim to the effect that use cases are not always necessary and
that they may be dispensed with later in a project hardly meets the criteria
of use case driven and led development laid out in Jacobson et al's OOSE and
in Jacobson's white paper on RUP.
Elliott
Phlip
>
> "XP is about Use Case led Architecture" in dream land. Geez, all the
XP'ers
> says in this regard is that they use a system metaphor and this is hardly
> driving development based upon integrating the, 4 + 1 RUP areas, led by
the
> '+1' area.
Elliot, I feel that you do yourself and the rest of us a disservice with
such comments. There is no XP commandment that says do no Use Cases. If an
XP team needs a Use Case, they will write it.
Jens Lundell
> > I am trying to convince my manager that XP may be the
> > way to go however I have some reservations about it
> > and need clarification on the following points:
> >
> > 1. XP claims not to need "great" programmers in order
> > to deliver. How competent do people have to be to
> > do XP? (Think people who never read a computing
> > book or magazine and have no CS degree, ie normal
> > corporate programmers as a baseline.)
>
> This is just like anything else. The better the programmers, the better the
> outcome. Doing XP with great programmers will have great results. Doing XP
> with average programmers will have average results (compared to other XP
> projects). Average programmers can use XP to great benefit, but great
> programmers will dervive even more benefit.
I believe XP demands more of the programmers than other processes such
as RUP. In XP the programmers don't have any specific roles. The part of
the system you work on constantly changes. This is great for the
programmers (they learn a lot) but I'm not sure if it's good for the
project as a whole (it takes time to learn). It might be beneficial for
the team to have this knowledge for future projects though. But from
what I understand, XPs don't like to speculate about the future.
In some environments, for example Java, it's not realistic that everyone
learn everything. Learning how to use
HTML/JSP/Servlets/Swing/EJB/Databases/CM tools etc efficiently takes a
long time. In Internet time, by the time you learned all this the
technology has changed.
-Jens
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
Patrick D. Logan
Universe wrote:
>
> "XP is about Use Case led Architecture" in dream land. Geez, all
> the XP'ers says in this regard is that they use a system metaphor and
> this is hardly driving development based upon integrating the, 4 + 1
> RUP areas, led by the '+1' area...
> The "+1" is the scenario (use case) view. The scenario view is "+1"
> because it is considered to be the primary and unifying view.
This is the same as with XP. The customer is in control by
prioritizing all the "key use cases" to use your own phrase.
> Further use case led means all-around investigation of all key use
> cases as a whole before the heart of high level production coding.
I have quoted this before and so I will only repeat the chapter here.
Please use Deja or read the book itself. Chapter 21 of Extreme
Programming Explained prescribes exactly this approach.
> That is not the same as all-around investigation of all key use
> cases as a whole before the heart of high level production coding.
Read chapter 21 and then tell me how it differs from what you prefer.
> Also RMartin's claim to the effect that use cases are not always
> necessary and that they may be dispensed with later in a project...
I am not sure what you are referring to. It certainly has nothing to
do with XP as far as I can tell. Please read chapter 21 of the book
and let's discuss it. Are you up for it?
--
Patrick Logan
patric...@home.com
Phlip
> Programmers don't want other programmers bitchin' about their code. Have
an
> XP people thought of that?
Ayup.
I don't want anyone bitching about my code.
Even, sometimes, about the same things as I /like/ about my code.
Therefor I take the time to learn what the bitchers will bitch about, and
then for about 67% of the opportunities to do whatever they dislike I DON'T
DO IT.
(Unless, of course, if I have a clearly superior and widely recognized
technical angle. In that case they are dead meat.)
And I expect others to return the favor.
Jeeze - some of these complainers might be the guy that OWNS what you'r
writing, or even the guy that PAYS them to get its features.
I work on they don't bitch, either.
I'm good at coding and have nothing to prove. I'm not sensitive to anyone
peering over my shoulder, even in the throes of creative passion. So the
actual challenge comes where I ensure a bitch-free environment.
And I do.
Sean Dwyer
XP people thought of that?
"Ronald E Jeffries" <ronje...@acm.org> wrote in message
news:0B859570A52102CB.4A6E1D40...@lp.airnews.net...
> On 11 Mar 2000 21:26:25 EST, "Phlip" <x@x.x> wrote:
>
> ><eXtreme dogma mode>
> >
> >Yes there is: They can't. The "eXtreme" in XP means the 12 Commandments
are
> >performed extremely, with no time (in a 40-hour week) for any baloney.
> >
> ></eXtreme dogma mode>
>
> Phlip, I feel that you do yourself and the rest of us a disservice
> with such comments. There is no XP commandment that says do no
Patrick D. Logan
Sean Dwyer wrote:
>
> Programmers don't want other programmers bitchin' about their code.
> Have an XP people thought of that?
XP recognizes the problems that arise when programmers think of it as
"their code". In XP there is no "my code" and "your code". There is
"our code" and there are principles that shape the code. If any of
the code is out of shape, anyone can fix it, and no one has to feel
like bitchin'. What could be better than that?
--
Patrick Logan
patric...@home.com
Robert C. Martin
Sean Dwyer <sean....@planet.nl> wrote in message
news:8ahf75$563na$1...@reader2.wxs.nl...
> Programmers don't want other programmers bitchin' about their code. Have
an
> XP people thought of that?
XP addresses this problem by eliminating the concept of "their code". No
single programmer owns a part of the code. Code is collectively owned by
the team. No single line of code is written by less than two people working
together. What's more, the pairs switch off frequently. So the code is
seen and touched by many people.
It is still possible that some folks will feel a certain amount of personal
ownership of what they consider to be "their code". If this causes them to
take a proprietary attitude, they aren't likely to be able to remain on the
team.
Sean Dwyer
Regards,
Sean Dwyer
"Sean Dwyer" <sean....@planet.nl> wrote in message
news:8ahf75$563na$1...@reader2.wxs.nl...
> Programmers don't want other programmers bitchin' about their code. Have
an
> XP people thought of that?
>
Robert C. Martin
Universe <univ...@radix.net> wrote in message
news:38d3cd21...@news1.radix.net...
>
> "XP is about Use Case led Architecture" in dream land. Geez, all the
XP'ers
> says in this regard is that they use a system metaphor and this is hardly
> driving development based upon integrating the, 4 + 1 RUP areas, led by
the
>
> The 4 key RUP areas are: logical, process, development, and physical
views.
because it
> is considered to be the primary and unifying view.
4+1 is an interesting way of characterizing an architecture. XPers do not
pay much attention to the 4+1 model. Rather they are driven by user
stories, and cause the software to evolve in such a way that the other 4
area are well taken care of.
>
> Further use case led means all-around investigation of all key use cases
as a
> whole before the heart of high level production coding. RMartin is clear
on
> saying once a set of stories is gotten from the client, XP projects can
code.
> That is not the same as all-around investigation of all key use cases as a
> whole before the heart of high level production coding.
Agreed, it is not the same. IMHO coding can begin as soon as the customer
has named enough user stories to provide good business value in the first
release. I think dithering around until you are sure you have all key use
cases before writing any code is a significant waste of time.
>
> Also RMartin's claim to the effect that use cases are not always necessary
and
> that they may be dispensed with later in a project hardly meets the
criteria
> of use case driven and led development laid out in Jacobson et al's OOSE
and
> in Jacobson's white paper on RUP.
I don't recall ever saying that use cases, or user stories, can be dispensed
with. What I *have* said is that old implemented story cards can be
discarded.
Robert C. Martin
Jens Lundell <jlun...@tns.net> wrote in message
news:38CBE5CE...@tns.net...
> "Robert C. Martin" wrote:
> >
> > Nick Thurn <nick....@db.com> wrote in message
> > news:8a1k3n$dn0$1...@kilmer.bain.oz.au...
> > > I am trying to convince my manager that XP may be the
> > > way to go however I have some reservations about it
> > > and need clarification on the following points:
> > >
> > > 1. XP claims not to need "great" programmers in order
> > > to deliver. How competent do people have to be to
> > > do XP? (Think people who never read a computing
> > > book or magazine and have no CS degree, ie normal
> > > corporate programmers as a baseline.)
> >
> > This is just like anything else. The better the programmers, the better
the
> > outcome. Doing XP with great programmers will have great results.
Doing XP
> > with average programmers will have average results (compared to other XP
> > projects). Average programmers can use XP to great benefit, but great
> > programmers will dervive even more benefit.
>
> I believe XP demands more of the programmers than other processes such
> as RUP.
Well, yes, the pace is a bit quicker than usual. However, RUP in and of
itself is not a process at all. It is a process framework that, if stripped
to its bare essentials is quite compatible with XP.
> In XP the programmers don't have any specific roles. The part of
> the system you work on constantly changes. This is great for the
> programmers (they learn a lot) but I'm not sure if it's good for the
> project as a whole (it takes time to learn).
Yes, it takes time to learn. On the other hand, projects are frequently
slowed down when the person with some critical knowledge that nobody else
has becomes an overloaded bottleneck.
> It might be beneficial for
> the team to have this knowledge for future projects though. But from
> what I understand, XPs don't like to speculate about the future.
XPers don't like to act on speculation or fear. Having knowledge
distributed through the team is good now because it eliminates the problem
of scheduling the talent to the job.
> In some environments, for example Java, it's not realistic that everyone
> learn everything. Learning how to use
> HTML/JSP/Servlets/Swing/EJB/Databases/CM tools etc efficiently takes a
> long time. In Internet time, by the time you learned all this the
> technology has changed.
So we hire the people who have the knoledge we need; and then we pair
program to spread the knowledge around as best we can. If we don't achieve
100% diffusion of knowledge, that's OK; we'll achieve some.