XP programming
Alessandro Federici
What do you guys think of it? Trying to get a feeling...
Rene Tschaggelar
I've been doing that for years, except I'm not a pair.
It is the way you work when there aren't real specifications.
There is always a 'Oh couldn't we change that', regardless how
progressed the project is. As the customer is the king (and pays for that)
the specifications are never settled.
Rene
--
Ing.Buero R.Tschaggelar - http://www.ibrtses.com
Phillip Flores
>
> [SNIP]
> There is always a 'Oh couldn't we change that', regardless how
> progressed the project is. As the customer is the king (and pays for that)
> the specifications are never settled.
>
he changed his mind 3 times which affected over 65% of the code. I
eventually told him to settle on one thing at a time.
--
Cheers,
Phillip Flores
+-----------------------------------------------+
| "Where did your time go today? Get VeriTime!" |
| http://www.pcfworks.com" |
| "The Delphi Catalog" |
| http://www.delphicatalog.com |
+-----------------------------------------------+
Scott Woods
What a disaster. You have to have an extremely disciplined group for this
to happen which I think is very hard to find. I have seen more talks about
the weather or "do it this way" by one of the dominant programmer
personalities.
Collective Code Ownership
Its the company that owns the code. Always will. Sure developers should be
able to make changes to code written by others. However I have seen many
new bugs introduced with this gem by "coders who know best". Myself
included.
On Site Customers
It is great to have customer input. In fact its a disaster not to find out
requirements up front. I just dont know of any companies that have an extra
employee that can hang out on site and be available whenever needed while we
code / design. How realistic is this one?
40 Hour Work Week
This has ALWAYS been the goal of a good software process. It is the result
of truthfully following the process from the developer to president. When
all nighters occure its the result of the unforseen, or your out of controll
on estimates, feature creep etc. I would love to see this, but I also
realize the unexpected will happen, changing the schedule. I also
understand the company I work with needs to produce revenue and to do that
sales / marketing needs to get their hands on our product. Hence I dont
mind some overtime.
I think a good initial architecture with code inspections among peers and a
good QA staff is the way to go (from my experience on successfull products).
Iman L Crawford
>Pair Programming
>What a disaster. You have to have an extremely disciplined group for
>this to happen which I think is very hard to find. I have seen more
>talks about the weather or "do it this way" by one of the dominant
>programmer personalities.
My experience has been the opposite. The most productive I've been was
when me and another guy worked together in a shared office.
--
Iman
"I was looking handsome,
she was looking like an erotic vulture" The Pixies
Kyle Cordes
>
> What do you guys think of it? Trying to get a feeling...
I have been using many of the XP practices recently with very good
results. In particular, I very much embrace test-intensive programming.
--
[ Kyle Cordes * ky...@kylecordes.com * www.kylecordes.com ]
[ Training and Development Services: Java, Delphi, PHP, ]
[ ASP, ASTA, Web Applications, n-tier systems, etc. ]
[ Delphi developers: Visit the BDE Alternatives Guide ]
Kyle Cordes
"Scott Woods" <GCSof...@email.msn.com> wrote in message
news:3afd4838_1@dnews...
> Pair Programming
> What a disaster. You have to have an extremely disciplined group for
this
> to happen which I think is very hard to find. I have seen more talks
about
> the weather or "do it this way" by one of the dominant programmer
> personalities.
I used to think this, and I have done a lot of sizable progams by myself
so I am definately the kind of person who would be prone to wanting to
be left alone.
But then I tried pair programming, and found that it works very well,
much better than I thought it would. If your pairs are talking about
the weather, they need more work to do :-) If one is dominating, that
is a harder problem to solve, but even if they keep dominating, this can
be a way for the more junior person to learn.
Kyle Cordes
> progressed the project is. As the customer is the king (and pays for
that)
> the specifications are never settled.
Customer changing requirements is not new. However, the XP approach of
trying very hard to keep the software soft so that changing requirements
can be dealt with effectively and efficiently is NOT very common outside
of XP.
I recommend Kent Beck's book.
Iman L Crawford
>XP Doesn't mean two people sharing the same office from what I've read.
>It means two people sharing the same office and working on the same code
>together.
Sorry that wasn't clear enough. We did work on the same code at the same
time. One would stand behind, sit next to, the other. One would do quick
prototypes, the other would work on a more formal design. We argued over
coding styles, best ways to do something, etc. Very productive, and I
learned a ton.
Iman L Crawford
>I have been using many of the XP practices recently with very good
>results. In particular, I very much embrace test-intensive programming.
One of the things about Python, is you have to have unit tests. I never
appreciated what it does unit testing does for you until Python.
Scott Woods
Scott Woods
the same code! Is one incompetent? Do I just have so much money I can
afford two hire two guys for the same job? I just don't get this. As a
professional programmer its our job to figure out problems and solve them.
A good process helps us by requirement management and detailed
specifications. There are always issues where questions arise outside ones
knowledge base. But way before XP became fashionable I just went to another
on my team and picked his / her brain.
Wayne Niddery (TeamB)
>
>My experience has been the opposite. The most productive I've been
was
>when me and another guy worked together in a shared office.
I think the issue is simply a question of *enforcing* this mode as a
rule. My opinion is it should not. I too know how productive it can be
to work closely with another, batting ideas back and forth -
especially when trying to solve a problem, but also when trying to
design something new.
However this tends to happen spontaneously, it cannot be forced. It
has to be the right two (or more) people at the right time. Forcing
two people to share a single computer and code "together" can be
counter-productive as often as not (maybe more often in fact).
My ideal situation is to let each programmer have their own station as
is traditional, but avoid isolating them (in spirit more than
physically). Encourage them to work together *as they like* (versus
making them feel guilty for conversing with each other "instead of
working"). If they feel free to turn from their own stations and walk
about to talk with their colleagues, they *will* talk about their
work - far more often than about the weather or last night's ball
game - and you will get the optimal benefit of "team" or "paired"
programming without taking away the feeling and need of independence.
This is also the best way to foster the *feeling* of a team among the
individuals and the enjoyment gained from a team that "works".
--
Wayne Niddery (WinWright Inc.)
RADBooks - http://members.home.net/wniddery/RADBooks/delphibooks.html
"At the apex of every great tragedy of mankind there stands the figure
of an incorruptible altruist" - Ayn Rand
Wayne Niddery (TeamB)
>What is the benefit to the company? I now am paying two developers
to work
>the same code! Is one incompetent? Do I just have so much money I
can
>afford two hire two guys for the same job? I just don't get this.
The idea of "two heads better than one". Being able (and encouraged)
to discuss your code with another while you are thinking and writing
*can* be very productive - exceeding the mere sum of two programmers
working separately - but please see my other post in this regard. I do
not agree with attempting to formalize this into a rule but rather
simply encouraging team members to freely consult and converse with
each other - it will then happen naturally.
Joe Hendricks
an XP Programming web site that fully
explains the whole concept ?
Thanks.
Joe
John Elrick
news:3afcd43d$1_1@dnews...
> http://www.zdnet.com/eweek/stories/general/0,11011,2714342,00.html
>
> What do you guys think of it? Trying to get a feeling...
Check some of the sites out - essentially it's trying to apply best
practices to short build cycles.
If you don't bring any prejudices to the table, most of XP actually reads
like common sense.
John Elrick
John Elrick
> What is the benefit to the company? I now am paying two developers to
work
> the same code! Is one incompetent? Do I just have so much money I can
Scott,
Before you speak too critically, review some of the data. One study
conducted by IBM back in the '70's showed an increase in overall
productivity using a form of pair programming (yes, it's that old) from an
average of 70 LOC per programmer day to 210 LOC per programmer day (or 420
LOC from the two developers working together rather than 140 LOC from the
two working separately).
It seems that when you have two good programmers working together, they
don't get stuck as much, plus they can keep up the documentation much
better.
If you were experiencing two guys getting together talking about the weather
instead of working, I'd hazard you saw a burned out group overdue for
vacation. IOW - you SAW the lack of productivity, rather than it staying
hidden.
Like all strategies, pair programming has its place - however, your
experience seems to indicate to me a serious problem within the
organization, not a problem with pair programming itself.
FWIW
John Elrick
Jonathan Wilson
<winw...@chaffhome.com> wrote:
>
>My ideal situation is to let each programmer have their own station as
>is traditional, but avoid isolating them (in spirit more than
>physically). Encourage them to work together *as they like* (versus
>making them feel guilty for conversing with each other "instead of
>working"). If they feel free to turn from their own stations and walk
>about to talk with their colleagues, they *will* talk about their
>work - far more often than about the weather or last night's ball
>game - and you will get the optimal benefit of "team" or "paired"
>programming without taking away the feeling and need of independence.
>This is also the best way to foster the *feeling* of a team among the
>individuals and the enjoyment gained from a team that "works".
Most of the companies I've worked for had this "group approach" to
work, sitting arround blowing smoke was not frowned upon (usually
small teams, departments... & isolated to some degree from the madding
crowed)... usually people would talk about work, tv, whatever... and
then turn back to the task in hand. work was defined in terms of
things done, not time spent, lines of code... but solid
implimentations. I'd say these companies were far more productive in
the IT (usually to the degree of leading the company as a whole) than
the companies that did not have such comraddary.
As to pair programming... only if both people like and respect each
other, and neither is dominant in all aspects of development. It needs
to be a better marriage than the marriage to your partner if it's to
work.
Jon
Integrated 400 Solutions Ltd.
Jonathan Wilson, AS/400 consultant/director
24 Hours: 07775 638904
Phillip Flores
>
> As to pair programming... only if both people like and respect each
> other, and neither is dominant in all aspects of development. It needs
> to be a better marriage than the marriage to your partner if it's to
> work.
>
not feel threatened then the concept will work well. I have been in a
similar situation and I must say it was great and I learned a lot of
things from the other developer as well.
Neil Butterworth
news:3afefa7b_2@dnews...
> "Scott Woods" <GCSof...@email.msn.com> wrote in message
> news:3afe07ea_2@dnews...
> > What is the benefit to the company? I now am paying two developers to
> work
> > the same code! Is one incompetent? Do I just have so much money I can
>
> Scott,
>
> Before you speak too critically, review some of the data. One study
> conducted by IBM back in the '70's showed an increase in overall
> productivity using a form of pair programming (yes, it's that old) from an
> average of 70 LOC per programmer day to 210 LOC per programmer day (or 420
> LOC from the two developers working together rather than 140 LOC from the
> two working separately).
This is only good if you think more LOCs as an absolute measure is good.
Most people think the opposite - the fewer LOCs needed to implement a
feature, the better. Do you have figures for feature implementation?
NeilB
Christopher Latta
news:3afeb6bd$1_1@dnews...
> My ideal situation is to let each programmer have their own station as
> is traditional, but avoid isolating them (in spirit more than
> physically). Encourage them to work together *as they like* (versus
> making them feel guilty for conversing with each other "instead of
> working"). If they feel free to turn from their own stations and walk
> about to talk with their colleagues, they *will* talk about their
> work - far more often than about the weather or last night's ball
> game - and you will get the optimal benefit of "team" or "paired"
> programming without taking away the feeling and need of independence.
> This is also the best way to foster the *feeling* of a team among the
> individuals and the enjoyment gained from a team that "works".
I think this is the right approach from my experience. It has to develop
naturally.
In a previous position, a six-person team sat in an open plan office.
Another guy and I had almost exactly the same approach to coding, and we
often discussed ways to solve problems, generally sitting in front of the
same terminal. I'd say we wrote around 60% of the application between us
using this method, with the others who worked in isolation not being as
productive.
My current (recently joined) position is also open plan with nine
developers, but discussion - or indeed any sort of noise - is frowned upon.
Another guy was doing a data conversion of Oracle and DataFlex for their
propriety legacy database product. He knew nothing about either product, and
was struggling for weeks to get the data into any sort of managable format.
Eventually I offered my assistance, imported his Oracle data into my machine
and in a couple of hours he had an app (written in Delphi of course - they
don't use Delphi and I was keen to show it off) which displayed all the
table names, table structure information and had an export facility into the
format of his choice. Sped up the process for him amazingly. Shortly after I
had a meeting with the project director where we discussed my little app. I
offered to write a similar one for the DataFlex tables, as it would only
take another hour or two. I was told that it was not my area, I had other
responsibilities, and I was not to do such an app. I just about had to beg
to be allowed to give the guy an ODBC driver I had for DataFlex to at least
make his life a little easier. I see him day after day trying to get the
data into some meaningful shape, while I have to deal with "my" issues. It
is frustrating because I know that together we could solve the problem in a
few days, rather than the weeks it is currently taking.
Christopher Latta
Kristofer Skaug
news:3afec0b0_2@dnews...
> Could someone please post a URL for
> an XP Programming web site that fully
> explains the whole concept ?
try http://www.extremeprogramming.org/
Kristofer
Kristofer Skaug
> What is the benefit to the company? I now am paying two developers
to work
> the same code! Is one incompetent? Do I just have so much money I
can
> afford two hire two guys for the same job? I just don't get this.
As a
> professional programmer its our job to figure out problems and solve
them.
I'm not an XP fanatic, and I certainly wouldn't want to see pair
programming elevated to religion. In fact I'm generally skeptical
about the whole thing, but there certainly are some potential benefits
from pair programming; In addition to the "peer review" (spotting each
other's errors) and being able to bounce ideas off each other, I think
one nice aspect of pair programming is in the specific role
assignments:
- The guy at the keyboard, doing "tactical programming" (how do I do
this algorithm, where do I declare the variables, which library
functions do I use, ...).
- The guy sitting next to him, doing "strategy" ("If we give this
method such&such interface, can we still reuse it polymorphically from
the base window?" etc)
Myself I am frequently switching between strategy and tactics while
coding, always catching myself at leaking mental agenda points (TODO
items) along the way. I do believe that both tactics and strategic
execution could be improved if the pair could actually do this
pattern.
Kristofer
Wayne Niddery (TeamB)
>Sped up the process for him amazingly. Shortly after I
>had a meeting with the project director where we discussed my little
app. I
>offered to write a similar one for the DataFlex tables, as it would
only
>take another hour or two. I was told that it was not my area, I had
other
>responsibilities, and I was not to do such an app.
I worked for almost two years at a large bank that was like this - do
*anything* that was not clearly assigned to you and you were hauled on
to the carpet. I resigned because I just could not stand that type of
environment, they were probably the most unproductive and unenjoyable
two years of my career.
Kyle Cordes
> >results. In particular, I very much embrace test-intensive
programming.
> One of the things about Python, is you have to have unit tests. I
never
> appreciated what it does unit testing does for you until Python.
In what sense do you "have to" have them in Python vs. anything else?
I've written pieces of Python code without unit tests.
There is definately a additional strong motivation to do unit testing in
weakly typed languages... you don't have compile time type checking.
Bud
http://www.greenspun.com/bboard/q-and-a-fetch-msg.tcl?msg_id=0045pQ
Bud
Kyle Cordes
> programming elevated to religion. In fact I'm generally skeptical
There are enough religions already. The things to do in regards to pair
programming is to try it and see if it works. If it does not help you,
don't do it. If it helps you, do it. But don't judge it until you
genuienly try it - as I said in another post it seems to work much
better in practice than "common sense" would suggest.
Kyle Cordes
to be written, debugged, tested, code reviewed, brought to a high level
of quality, etc., you will get there sooner/faster/cheaper when pair
programming than without.
Perhaps you will pay two people to get it right the first time, rather
than one person at a time to rework / rethink it 5 times, have it fail
in production, lose an important customer, etc. :-)
--
[ Kyle Cordes * ky...@kylecordes.com * www.kylecordes.com ]
[ Training and Development Services: Java, Delphi, PHP, ]
[ ASP, ASTA, Web Applications, n-tier systems, etc. ]
[ Delphi developers: Visit the BDE Alternatives Guide ]
"Scott Woods" <GCSof...@email.msn.com> wrote in message
news:3afe07ea_2@dnews...
Iman L Crawford
>In what sense do you "have to" have them in Python vs. anything else?
>I've written pieces of Python code without unit tests.
With Python, it's easier to just go ahead and do them anyway. It saves you
a lot of time, and is pretty easy to run the test everytime you "compile*
the script.
>There is definately a additional strong motivation to do unit testing in
>weakly typed languages... you don't have compile time type checking.
I wouldn't call Python weakly typed, you can't mix strings, ints, reals etc
without some type of conversions. It's more dynamically typed. The right
side of the equal determines the type of the variable.
Kyle Cordes
> >I've written pieces of Python code without unit tests.
> With Python, it's easier to just go ahead and do them anyway. It
saves you
> a lot of time, and is pretty easy to run the test everytime you
"compile*
> the script.
Again, how is this Python specific?
I do the same thing in Java and Delphi. In Java I have it fully
automated (build process runs tests every time), in Delphi I'm still
putting all the pieces together to do that.
> >There is definately a additional strong motivation to do unit testing
in
> >weakly typed languages... you don't have compile time type checking.
> I wouldn't call Python weakly typed, you can't mix strings, ints,
reals etc
> without some type of conversions. It's more dynamically typed. The
right
> side of the equal determines the type of the variable.
You are correct, I was wrong.
Iman L Crawford
>> With Python, it's easier to just go ahead and do them anyway. It
>saves you
>> a lot of time, and is pretty easy to run the test everytime you
>"compile*
>> the script.
>
>Again, how is this Python specific?
>
>I do the same thing in Java and Delphi. In Java I have it fully
>automated (build process runs tests every time), in Delphi I'm still
>putting all the pieces together to do that.
I've never felt compelled to do them with Delphi, i would run through my
tests manually, through the application. With Python I found it almost
required to do unit testing, just to catch typos. I'm not saying it's
Python specific, it's just Python was the first time I saw the benefits of
unit testing.
John Kaster (Borland)
>
> Pair Programming
> What a disaster. You have to have an extremely disciplined group for this
> to happen which I think is very hard to find.
I don't think the discipline matters as much as a personality match. For
example, in my 20 years, I've worked with ... oh ... 5 other people in
this manner VERY successfully. (Jeff Overcash is the most recent.)
I find my thought process is actually slightly *different* and improved
when I have someone else right next to me who is technically savvy.
Perhaps because I want to make sure I don't embarrass myself <g>.
You can also focus on the solution rather than second guessing yourself
if you can trust the other person to catch your mistakes.
Some of the others were Dan Miser, Anton van Straaten, Ali Davachi and
Rob Hannah.
As you can see, the good experiences stick out in my mind.
I highly recommend partner programming by whatever name you call it --
provided you have the right partner.
--
John Kaster, Borland Developer Relations, http://community.borland.com
$1150/$50K: Thanks to my donors!
http://homepages.borland.com/jkaster/tnt/thanks.html
Buy Kylix! http://www.borland.com/kylix * Got source?
http://codecentral.borland.com
The #1 Java IDE: http://www.borland.com/jbuilder
Kyle Cordes
> >automated (build process runs tests every time), in Delphi I'm still
> >putting all the pieces together to do that.
> I've never felt compelled to do them with Delphi, i would run through
my
> tests manually, through the application. With Python I found it
almost
> required to do unit testing, just to catch typos. I'm not saying it's
> Python specific, it's just Python was the first time I saw the
benefits of
> unit testing.
A big point of unit testing is that programmers always do unit
testing... with little throwaway tests, by running through some tests
manually, etc. But the advantages of doing automated pervasive unit
testing are huge... once you see the benefits in langage X it should be
easy to see that it would transfer to language Y.
Have you tried out DUnit yet?
Iman L Crawford
>Have you tried out DUnit yet?
Not yet, I'm mostly doing maintenance development with Delphi right now.
Just adding/modifying reports. I'll be updating/redeveloping this year,
and if I go with Delphi on the client I'll keep it in mind.
Edwin Keeton
>
> Before you speak too critically, review some of the data. One study
> conducted by IBM back in the '70's showed an increase in overall
> productivity using a form of pair programming (yes, it's that old)
There are also studies showing dramatic gains in productivity by giving
programmers quiet, separate offices with minimum standards of floor
space and desktop space, doors that close, etc. The ideal environment
might allow and encourage both styles of working at different times.
(This morning we work together in pairs, later on we decide to work on
our own. Then we work in pairs again tomorrow, etc.)
John Elrick
news:MPG.156a12c27...@10.1.1.250...SNIP
> space and desktop space, doors that close, etc. The ideal environment
> might allow and encourage both styles of working at different times.
> (This morning we work together in pairs, later on we decide to work on
> our own. Then we work in pairs again tomorrow, etc.)
Concur with this Edwin.
John
Kyle Cordes
Nonetheless, both sets of advice (pair programming, quiet offices) have
been and will probably continue to be widely ignored in practice. The
most common working environment for software development seems to be the
cube farm, which is far from ideal is many ways. It seems like folly to
save money on furniture and drywall (which aren't really *that*
expensive) at the cost of needing more software developers (which *are*
really that expensive) to get the job done.
John Elrick
news:3b00557d$1_1@dnews...
> > > Before you speak too critically, review some of the data. One study
> Nonetheless, both sets of advice (pair programming, quiet offices) have
> been and will probably continue to be widely ignored in practice. The
> most common working environment for software development seems to be the
> cube farm, which is far from ideal is many ways. It seems like folly to
> save money on furniture and drywall (which aren't really *that*
> expensive) at the cost of needing more software developers (which *are*
> really that expensive) to get the job done.
This is the "the programmer is an assembly line worker" mentality rearing
its ugly head.
John Elrick
Mark Reichert
news:3aff62ca_2@dnews...
> data into some meaningful shape, while I have to deal with "my" issues. It
> is frustrating because I know that together we could solve the problem in
a
> few days, rather than the weeks it is currently taking.
To some managers, territoriality is everything.
--
Please respond only in the newsgroup. I will not respond
to newsgroup messages by e-mail.
John Elrick
news:3b013ba0_1@dnews...
> "Christopher Latta" <nob...@nowhere.not> wrote in message
> news:3aff62ca_2@dnews...
> > data into some meaningful shape, while I have to deal with "my" issues.
It
> > is frustrating because I know that together we could solve the problem
in
> a
> > few days, rather than the weeks it is currently taking.
>
> To some managers, territoriality is everything.
...even over success. Yes, I know one of them. Question: how do you
virtually destroy a department in a supportive, growing and profitable
organization? Answer, make someone unqualified the manager.
John Elrick
Chris Morris
> an XP Programming web site that fully
> explains the whole concept ?
I go out of town and the ngs erupt with threads on XP. Wacky.
Better late than never, I've got a mess of links here:
http://clabs.org/xpref.htm .
Chris Morris
DUnit Co-Admin
http://dunit.sourceforge.net
Clay Shannon
eXtreme Programming Programming?
or XP (the OS) Programming?
"Alessandro Federici" <al...@bigfoot.com> wrote in message
Alessandro Federici
Thanks everybody!