>>>>> Erik Naggum writes:
* John M. Adams
> Planning is underway for a Next Generation Space Telescope
> (www.ngst.stsci.edu). Those currently responsible for software strategy
> believe that using lisp on this project would be a mistake along the
> lines of `lisp is not a mainstream technology and therefore there would
> be maintenance nightmare because it is difficult to hire lisp
> programmers'.
Erik> Have they (you) actually _tried_ to hire Common Lisp programmers?
Erik> Have they talked to people who have actually tried?
Erik> I wonder if this is just another Lisp myth.
I have. For about 9 months now. This is the story of how we
built our programming team.
Yes, it's hard to recruit lispers. But remember -- we're a small
outfit, and we're in Australia. It *is* fair to say that the pool
within Australia is very poor. Australia is _very far_ from anywhere
else.
Nonetheless, we built a very high quality (IMO) team, which has
hovered at 5-6 programmers, but which, over that time span, has
encompassed 9 people total.
Of these, one was a dud, one was wonderful but only wanted to come for
a short contract (though he has expressed interest in coming back),
one became our CTO, and the others we convinced to stay with us. They
mostly came from North America (with one Korean exception).
One was trained in house.
One is me, who is self trained.
Two totally excellent potential candidates eventually turned us down.
My take on this is that, on the whole, the people who are willing to
move their family across a continent to have to opportunity to work in
a language they know doesn't suck form a highly self selected group
which tend to be highly motivated and talented.
So, is it a myth? Are you better off carefully building and nurturing
a small, talented, productive group, or buying "off the shelf"
`programmers' who search through hash tables with a linear search?
(Don't laugh -- I've seen this from people paid to program. In fact,
I've seen worse.)
We did this soul searching when we started our project. We considered
Python, Lisp, Java. All things considered, I think we made the right
choice.
I sympathise with the folks at STSCI. But they're writing
fantastically complex software, ideally suited, I would think, for a
small, sharp team using the best tools.
Erik> Alain Picard recently requested something along the same lines, too.
Erik> He seems to have received a whole bunch of really useful replies.
Yes, and at the request of Kent Pitman (and, heck, just because
it's a good idea and the right thing to do), I'll post a summary
of what I received Real Soon Now, Promise.
--
It would be difficult to construe Larry Wall, in article
this as a feature. <·····················@netlabs.com>
Alain Picard <·······@optushome.com.au> writes:
> Yes, it's hard to recruit lispers. But remember -- we're a small
> outfit, and we're in Australia. It *is* fair to say that the pool
> within Australia is very poor. Australia is _very far_ from anywhere
> else.
>
Have you considered letting people stay where they are and
coordinating the work over mailinglists/internal newsgroups etc. with
only a few person to person meetings a year?
--
Lieven Marchand <···@wyrd.be>
Gla�r ok reifr skyli gumna hverr, unz sinn b��r bana.
>>>>> Lieven Marchand writes:
Lieven> Have you considered letting people stay where they are and
Lieven> coordinating the work over mailinglists/internal newsgroups etc. with
Lieven> only a few person to person meetings a year?
No, not seriously. We do a lot of extreme programming, with a
lot of emphasis on pair-programming. The one time we tried to
dish out work remotely for a 1 month period failed dismally.
Part of the problem is we try to keep "work packets" as small
as possible, and to eliminate notions of code ownership.
In fact, if anybody knows of any (commercial, with deadlines) project
which has used the approach described by Lieven, I'd love to read
about it.
--
It would be difficult to construe Larry Wall, in article
this as a feature. <·····················@netlabs.com>
Alain Picard <·······@optushome.com.au> writes:
> >>>>> Lieven Marchand writes:
>
>
> Lieven> Have you considered letting people stay where they are and
> Lieven> coordinating the work over mailinglists/internal newsgroups etc. with
> Lieven> only a few person to person meetings a year?
The lisp product I've been working was developed with a completely
dispersed team. I've talked about it here before too. One in Mexico,
one in London, one in Berkeley, one in Chicago, and the manager in New
York. As a team we had no problems working in such an environment
since most of us were brought up on Free Software and all of the
distributed development tools that community has created. We used IRC
and mailing lists for communication, with phone calls for the more
loquascious interactions. For source control we used CVS, which has
what Ken described as "soft checkouts", allowing more than one person
to work on a file at a time.
Recently however the team is coagulating in Chicago due to the
personal interests of the developers (all of whom lived in Chicago at
one time before), so we will prolly turn into a core Chicago team with
developers in remote places. This could possibly be more difficult
than the previous arrangement because there is a tendency to forget
about IRC and email and the remote people when you have a group all in
one place. Luckily, our manager will still be remote, so alot of the
communications still needs to be done electronically.
> In fact, if anybody knows of any (commercial, with deadlines) project
> which has used the approach described by Lieven, I'd love to read
> about it.
Our lisp product is commercial[1], and we had/have deadlines. It's a
web-based scheduling system for libraries and media center resources.
It's been in production at a large art school in Chicago for months
now.
I've also programmed on, and managed commercial projects, with
deadlines, but not in Lisp, which had remote teams (one had teams in
Chicago and Malaysia) which were brought to completion succesfully.
And even when we have developers in the same city, they work from home
frequently, especially years ago when we first started and had no
office space for everyone.
We don't do much with the extreme programming tactics so we never had
issues with how to handle pair programming and the like over remote
connections. Even when in the same location we seldom did pair
programming, prefering something more like barnyard programming, where
you could get up and look at other work, or shout across the room at
them if you needed some advice. This was good because personal
victories and defeats were distributed across the whole group, which
was good for our morale. One person having a great hack could offset
your day of spinning wheels, and let you relax at the end of the day
and not get all uptight and stressed. Copious amounts of beer and
Bari Food's subs[2] helped of course.
[1] The product itself is commercial, but the toolkits we built for it
are Free Software. http://alpha.onshore.com/lisp-software
[2] Best subs in Chicago, possible the U.S. We had a web-based order
collection and faxing system built especially for them by one of
our developers as a going away present.
--
Craig Brozefsky <·····@red-bean.com>
All your base are belong to us. Somebody set us up the bomb
In the rich man's house there is nowhere to spit but in his face
-- Diogenes
[comp.software.extreme-programming removed.
http://world.std.com/~pitman/pfaq/cross-posting.html]
Alain Picard <·······@optushome.com.au> writes:
>
> >>>>> Lieven Marchand writes:
>
>
> Lieven> Have you considered letting people stay where they are and
> Lieven> coordinating the work over mailinglists/internal newsgroups etc. with
> Lieven> only a few person to person meetings a year?
>
> No, not seriously. We do a lot of extreme programming, with a
> lot of emphasis on pair-programming.
Can you say more about (a) what this is (I'm assuming you mean 2-person
teams, but...), (b) why it doesn't work over a
remote connection, and (c) why there is a reason to believe it exceeds
what I'm assuming is the alternative here of "single" progrmaming?
I'm not trying to bait you here, but I've done a lot of my career by
telecommuting and am curious/suspicious about claims by people that
it doesn't work. I know a few cases where it has to be managed carefully,
but a lot of the barriers I've heard bandied about I've come to believe
are just myths and prejudices. I think Lieven's right to raise this question.
> The one time we tried to
> dish out work remotely for a 1 month period failed dismally.
In my experience, anyone who tries this for less than 3-6 months is not giving
it time to work. That's like saying "We tried Lisp for 1 month and it didn't
seem to be working, so we went back to C." or "We tried computers for a month
but weren't proficient so we went back to doing things on paper." Changes
take time. That doesn't make them not productive in the long run.
I don't know what product you make, but if your customers said they tried it
for a month and it failed dismally, would that necessarily be a failure of
the product or do you acknowledge that some major changes in a system take
a while to work through?
> Part of the problem is we try to keep "work packets" as small
> as possible, and to eliminate notions of code ownership.
I suspect you could get a better source control system. I've seen shared
sources work fine over a distance at both Symbolics and Harlequin, I think
because each of these supported the notion of "soft claims", so that one
person's checkout didn't lock out another from making a change they really
needed to make. I've found Microsoft's visual source safe a lot more
annoying in this regard since only one person can check out something at
a time. But I wouldn't blame that back on the notion of being remote.
> In fact, if anybody knows of any (commercial, with deadlines) project
> which has used the approach described by Lieven, I'd love to read
> about it.
Why does it being written up give it more credibility? Who with deadlines
and a working theory of how to get work done has time to write these things
up?
It wasn't written up, But a great deal of the Symbolics Lisp Machine
was written/debugged by programmers at a distance from one another.
Some across the building or up or down a floor and too lazy to walk;
some across the country. Even when we were colocated we often didn't
come out of our offices to talk to one another, since the efficient
communication was carried on online.
Kent M Pitman <······@world.std.com> writes:
> > No, not seriously. We do a lot of extreme programming, with a lot
> > of emphasis on pair-programming.
>
> Can you say more about (a) what this is (I'm assuming you mean
> 2-person teams, but...), (b) why it doesn't work over a remote
> connection, and (c) why there is a reason to believe it exceeds what
> I'm assuming is the alternative here of "single" progrmaming?
Real pair programming is far superior (in my opinion) to things done
remotely. Real-time verbal communications, staring at the same code,
then going over to a blackboard, or whipping out a piece of paper to
write on. If you're working with someone who's (say) nearly your
equal, there are huge benefits:
o you watch over one another, with respect to typos, conceptual
mistakes, misinformation, interpretation, etc.
o you learn what they know but you didn't, and vice versa.
o you don't spend forever trying to do miniscule things because you
hit a roadblock that they simply know how to deal with.
o you help each other steer clear of wrong turns, which happens all
the time normally (i.e. when people code alone).
o the company has AT LEAST TWO people who can explain every line of
code -- an important sense of security that companies *should*
want.
o it's can be a *lot* more fun, unless your ego is one which needs to
always be in charge, or simply can't get along with most people.
o you become aware of compromising with respect to coding styles.
o the fact that the code is comprehensible to two people from the
outset means that it's more likely to be universally
comprehensible. What often makes senes to one and only one person
can be pretty cryptic.
o mentally, the idea of ownership changing to co-ownership is
advantageous, because you have twice as many people who are
authorities.
That's my take. I do my best to convince people all the time that
development can take place remotely, but admit (from experience) that
it pales in comparison to what pair programming offers.
An example is a Lisp project I'm working on now. I work remotely for
a company, but the one time I traveled to work with another developer
we did in a few days what seemed to be taking weeks.
It's not that singleton-style programming can't be effective; it's
that it's inferior to the proposed alternative. Adding remoteness
makes the disparity even greater.
Again, all just my opinions. Having worked remotely and alone,
remotely with others, in pair situations, and on-site but in my
cubicle, I think the best deal, productivity-wise is pair. Of course,
my favorite is remote pairs, with frequent discussion (that way I can
spend more time with my cat).
Lastly, some could undoubtedly argue that for those who know what
they're doing, this pair programming is not ideal. But consider that
the purpose of a *company* is overall productivity, and having
information flow among developers towards a group where people's
knowedge is closer to the union of information is best. Also, not
everyone is that guru. In fact, few are. So again, pair programming
is (in my opinion) better collectively.
dave
>>>>> Kent M Pitman writes:
KP> Alain Picard <·······@optushome.com.au> writes:
[telecommuting thread being discussed...]
>>
>> No, not seriously. We do a lot of extreme programming, with a
>> lot of emphasis on pair-programming.
KP> Can you say more about (a) what this is (I'm assuming you mean 2-person
KP> teams, but...), (b) why it doesn't work over a
KP> remote connection, and (c) why there is a reason to believe it exceeds
KP> what I'm assuming is the alternative here of "single" progrmaming?
Well, it's a large topic which you can read about by searching
for ExtremeProgramming in Google, or going to c2.com's wiki.
But the upshot is two people sit at one keyboard to write every
test and line of production code in the system.
Also see a post by D. Bakhash, who speaks from personal experience
and offers an independent corroboration of this style of working.
KP> I'm not trying to bait you here, but I've done a lot of my career
KP> by telecommuting and am curious/suspicious about claims by people
KP> that it doesn't work. I know a few cases where it has to be
KP> managed carefully, but a lot of the barriers I've heard bandied
KP> about I've come to believe are just myths and prejudices. I think
KP> Lieven's right to raise this question.
I didn't want to imply that it couldn't work. I did say that when we
tried it, the experiment was a failure. I would also say that given
our current style of development, I don't see how we could
successfully use remote collaboration. This is actually very sad, as
it limits our pool of potential programmers.
The issues relating to code ownership are not issues of software
source control, they are psychological issues that a programmer
does not "own" the code that they wrote. So on our team, anyone
of us feels completely free to modify any method, written by anyone
else. We don't even go over to Joe and say "Hey, Joe, is it Okay
if I change this method here to do X instead of Y?" We just do it.
We re-run all the tests, and if they pass, we commit the change.
End of story. For this to work, we must all have a certain level
of familiarity with the entire code base.
Clearly, this model does not scale to large teams, and clearly,
this model does not scale to someone 5,000km away writing code
I never get a chance to look at.
KP> In my experience, anyone who tries this for less than 3-6 months
KP> is not giving it time to work. [SNIP]
Red herring here -- we did it for one month because that's how long
our guy was away from the country. We didn't want to even try it
in the first place.
Now that I think about it, I think the main problem was one of
"out of sight, out of mind". There was just too much to do "here" to
take time to properly oversee, manage, and collaborate with the remote
employee. I know for a fact that it wasn't _his_ fault, but,
nevertheless, we ended up keeping very little of what he wrote during
this period.
[Actually, as a side note, there *is* one form of "remote
collaboration" which has worked for our company, and that is the
support given to us by our vendor. We report bugs, and they get fixed
within a few days. But I think that's a special case, where the "problem
specification" is quite simple: usually a backtrace of something which
should have worked but didn't. In our everyday development, most of
the effort goes into clearly defining and communicating the
requirements among all members of the company. We work on a fairly
conceptually complex application.]
KP> I suspect you could get a better source control system.
See above remarks about problems being psychological, not technical.
(we use CVS, btw.)
>> In fact, if anybody knows of any (commercial, with deadlines) project
>> which has used the approach described by Lieven, I'd love to read
>> about it.
KP> Why does it being written up give it more credibility?
Wrong track. It doesn't lend it any credibility whatsoever, but it
does let me learn about other people's experiences, which may be
different from mine. I was fascinated to read about Craig Brozefsky's
experience in another post. I still don't think this will work for
our company, but I'm interested to know how other people manage to
make their processes work. (I'm into process/methodology/whatever it
takes to deliver software for my employer. I'm fairly pragmatic about
it. I'm even willing to push little known but superior technologies,
at times...)
KP> It wasn't written up, But a great deal of the Symbolics Lisp Machine
KP> was written/debugged by programmers at a distance from one another.
I'd love to hear more about this. How did you "divvy up" the work?
Was there a central architect? I'm suspecting almost every programmer
involved in that effort was in the God/guru class, which is not the
case anywhere I've ever had the chance to work.
I realize that none of this has anything to do with lisp anymore... so
say the word and I'll cease and desist! :-)
--
It would be difficult to construe Larry Wall, in article
this as a feature. <·····················@netlabs.com>
>>>>> "Alain" == Alain Picard <·······@optushome.com.au> writes:
Alain> clearly, this model does not scale to someone 5,000km away
Alain> writing code I never get a chance to look at.
What difference does it make if they're 5000km away or at the next
desk? Presuably in either case you can see other people's code after
they've committed it.
>>>>> "Erik" == Erik Naggum <····@naggum.net> writes:
Erik> * Paul Rudin <··········@scientia.com>
>> What difference does it make if they're 5000km away or at the next
>> desk?
Erik> Unless those 5000 km are vertical, which I think would be
Erik> interesting, there's this non-flat earth thing which makes
Erik> coordinating people and daylight and working hours a pain.
I was just picking up on Alain's suggestion that physical seperation
implied that you "never get a chance to look" at code. Obviously there
are some issues...
>> Presuably in either case you can see other people's code after
>> they've committed it.
Erik> That may be too late, but there might be a useful discipline
Erik> in letting people in on your work at specific stages, only.
In part it depends on how frequently you commit changes. Keeping a
branch for work in progress and committing often may be a good idea?
--
Mossad colonel strategic Uzi FSF cryptographic Rule Psix Legion of
Doom Ft. Meade Peking Honduras NSA South Africa bomb Noriega
Paul Rudin <··········@scientia.com> writes:
>
> >>>>> "Erik" == Erik Naggum <····@naggum.net> writes:
>
> Erik> * Paul Rudin <··········@scientia.com>
> >> What difference does it make if they're 5000km away or at the next
> >> desk?
In my experience, the virtue of being at a distance is both people get their
hands on a keyboard. When you work together in the same room, one hogs the
keyboard and one watches. This is disempowering.
If you both want to drive the same editor buffer, there may not be tools for
that, but I bet the tools are not hugely better for people in the same room.
> Erik> Unless those 5000 km are vertical, which I think would be
> Erik> interesting, there's this non-flat earth thing which makes
> Erik> coordinating people and daylight and working hours a pain.
>
> I was just picking up on Alain's suggestion that physical seperation
> implied that you "never get a chance to look" at code. Obviously there
> are some issues...
I've been on California, Hawaii, or Japan time ever since college.
Some of these "issues" could normalize things.
> >> Presuably in either case you can see other people's code after
> >> they've committed it.
And the only reason you wouldn't see it before would be failiure to invest
in the obvious programmatic technology to support this so-called important
activity.
I guess my point being that if I had one-person boats and invented two-person
boating, I'd expect to have to do some re-tooling before I could win. But
somehow what I'm hearing suggests people are just blundering ahead with tools
designed for a single person and then claiming it can only work locally.
What a surprise.
> Erik> That may be too late, but there might be a useful discipline
> Erik> in letting people in on your work at specific stages, only.
>
> In part it depends on how frequently you commit changes. Keeping a
> branch for work in progress and committing often may be a good idea?
Having a three-way editor buffer showing mine/theirs/committed might be the
way to handle this. Again, I'd rather type than speak a suggestion any day.
I can do it much faster and with much greater precision. The qualification
for wanting to do this is not "being a good programmer" but rather "being
a good typist", and is dead easy to assure without having to be (as suggested
in an earlier post) a "guru" or "god" or whatever other word people want to
attach to certain programmers in order to dismiss them.
I suspect this entire line of thought is analogous to "theory X vs theory Y"
management--that these are competing techniques that work well for some people
and not for others. (Personally, I think I'd hate this mode of operation and
would ultimately decide it was a waste of my life and quit the company. But
I don't doubt it works for others. In some ways, I even learned this way back
at MIT, and I don't doubt that it's useful as a local tactical strategy even
to me in certain situations (which is maybe what Erik was suggesting above
when he said "at specific stages", though maybe he meant something more formal
than what I'm thinking--hard to tell).
My take on the thing based on this limited discussion is the
following: if it is, as I tentatively surmise, like the theory X/Y
issue, then deciding to have a shop that either is/isn't into it as a
wholesale concept sounds very bad. Like having a manager who thinks
all employees will respond either to X or Y. (For those not familiar
with the X/Y debate, by the way, it's a push/pull issue in motivating
employees. I can never remember which is which, but it says
essentially: some employees respond well to being scolded, that is,
they are naturally lazy and need to be kicked a lot; while others
respond well to praise, that is, they are naturally ambitious and need
merely to be encouraged.) You cannot simply decide that you will hire
only one kind because you may misclassify them and it's certainly not
grounds for firing if there is a reasonable management step you can
take to get them to be working up to par. I Have to say I imagine the
same is true of XP. It may well be that it's fun to have a whole shop
full of one kind of person, but it sounds both discriminatory and
short-sighted to me. It seems to me that a quality manager would
observe that someone was not "getting it" or that someone was "wanting
to share" and would pair such people, while observing that others did
fine on their own. Some people, for example, might work well on their
own and yet still generate fine documentation or other design specs
for others to look at; it is not necessarily the case that someone
working on their own is hogging information in a way that doesn't help
the company. Nor is it the case that if they are, the organization can be
helped by forcing them to work with another since this might just bring
their productivity to zero with no net benefit to the company; I guess
if you think that's a plus, that's another matter, but it doesn't sound
like a plus to me. If for no other reason, it's playing games with a
person's career by making them feel worthless in a situation where there
was every reason to suppose them "worthful" (were there such a word).
I may be off the mark on this, not ever having seen it, but all I can say
is that it was common at the MIT AI Lab for people to work in all of these
modes: sometimes someone would look over your shoulder, see you were losing,
and decide to spend a day just coding with you. But the same person on
another day would slam the door and say "forget it". Some people were
never helpful to others, and some people made a career of it. And the lab
benefitted from each and every type of person, as nearly as I can tell.
I think the underlying reason for this goes back to what I claim is the
basis of intelligence (and by implication, intelligent management/system
design): shift of paradigm to accomodate bottlenecks. No single paradigm
is going to be stronger than the ability to intelligently shift paradigms
to accomodate a special need. It isn't the selection of a good paradigm
that characterizes intelligence, it's the ability to dynamically reselect
paradigms to keep a system functioning optimally given that all components
are not always good for all purposes. Locking out someone who doesn't thrive
in XP (or someone who does!) would seem inappropriate to best performance
under this thory.
JMO.
Kent M Pitman <······@world.std.com> writes:
> In my experience, the virtue of being at a distance is both people get their
> hands on a keyboard. When you work together in the same room, one hogs the
> keyboard and one watches. This is disempowering.
>
It's the basis of one XP practice known as pair programming. In one
session, the person driving (hogging the keyboard in your terms) can
change any number of times and he or she can't add anything the other
programmer doesn't agree with. A mode of "let me finish these 100
lines of code and I'll explain it to you" is strongly discouraged.
> I suspect this entire line of thought is analogous to "theory X vs theory Y"
> management--that these are competing techniques that work well for some people
> and not for others. (Personally, I think I'd hate this mode of operation and
> would ultimately decide it was a waste of my life and quit the company. But
> I don't doubt it works for others. In some ways, I even learned this way back
> at MIT, and I don't doubt that it's useful as a local tactical strategy even
> to me in certain situations (which is maybe what Erik was suggesting above
> when he said "at specific stages", though maybe he meant something more formal
> than what I'm thinking--hard to tell).
You shouldn't limit XP to this one practice, it isn't even the most
important. More important are things like the Planning Game and Test
Driven Development. One of the things where it would conflict most
with Lisps philosophy is in their preference for "the simplest thing
that works", also embodied in the phrase "You aren't gonna need it
(YAGNI)". The argument is that you should not generalize a
method/object/module beyond what is necessary for the test case you're
working on, because when you actually need the extra generality,
you'll have a better understanding of both the problem space and the
solution space. Lisp excels in designing solutions at more general
levels "to do the right thing".
--
Lieven Marchand <···@wyrd.be>
Gla�r ok reifr skyli gumna hverr, unz sinn b��r bana.
Lieven Marchand wrote:
> Kent M Pitman <······@world.std.com> writes:
>
>> In my experience, the virtue of being at a distance is both people get
>> their
>> hands on a keyboard. When you work together in the same room, one hogs
>> the
>> keyboard and one watches. This is disempowering.
>>
>
> It's the basis of one XP practice known as pair programming. In one
> session, the person driving (hogging the keyboard in your terms) can
> change any number of times and he or she can't add anything the other
> programmer doesn't agree with. A mode of "let me finish these 100
> lines of code and I'll explain it to you" is strongly discouraged.
I have to say that I have no real experience with XP but my personal
experience showed that this kind of working doesn't work very good.
The problem _is_ that both people _may_ have an equally good idea - but
often both ideas differ greatly in the basics. so it will happen that the
watching person will constantly try to push the writer in his direction,
which will then lead to an mix-solution that is really dirty when it works
at all. IMHO sometimes it is more efficient to let people express their
whole idea before trying to understand what they mean.
Regards,
Jochen
In article <··············@ID-22205.news.dfncis.de>, Jochen Schmidt wrote:
> ...
>The problem _is_ that both people _may_ have an equally good idea - but
>often both ideas differ greatly in the basics. so it will happen that the
>watching person will constantly try to push the writer in his direction,
>which will then lead to an mix-solution that is really dirty when it works
>at all. IMHO sometimes it is more efficient to let people express their
>whole idea before trying to understand what they mean.
what i found useful is to get the participants together frequently in the
early stages to hash their ideas out, with breaks in between where they can
go away, think over the arguments and try a few experiments before resuming
the discussions. once the framework has been hammered out regular meetings
where problems get discussed are still useful.
hs
Jochen Schmidt <···@dataheaven.de> writes:
> The problem _is_ that both people _may_ have an equally good idea - but
> often both ideas differ greatly in the basics. so it will happen that the
> watching person will constantly try to push the writer in his direction,
Heh. I've often said this about language standards: that any one of
us could design a better standard than us as a group, exactly because
it would then have a single, coherent point of view and style. When
we introduce democracy, or any consensus process other than simple
dictatorship, we get weird combination effects that often are not what
anyone wanted. SOMETIMES that's better, but often it's not, and the
worst part about it is that no individual person is ever adequately
prepared to defend the outcome because it always comes down to just
"that's the way the votes came out" or because each party ends up at
some point saying "sorry, that was out of my control".
> which will then lead to an mix-solution that is really dirty when it works
> at all. IMHO sometimes it is more efficient to let people express their
> whole idea before trying to understand what they mean.
If understanding is the goal. I almost get the impression this is
like neural nets, where robustness of the net is what's the key goal.
In such a system, coherence and understanding are rarely the oucome.
Even in the human brain, while it has as a goal to understand, there
is no understanding achieved of how it understands. You could say the
same might be true of the XP outcome as I've heard it described thus
far.
Well, I'm all for interesting experiments and I guess it sounds as
interesting as anything. I've no desire to claim it can't work. I
just also have no desire to have this be how I do programming.
I program in order to improve my understanding of the world, not to
achieve a goal. I pick goals that offer me interesing things to
learn. Engaging in a practice whose goal was to divert me from any
sense of personal satisfaction and any sense that I could construct
and carry through a coherent throught experment without being derailed
would not be satisfying to me. I'd change careers first.
But I know people who wouldn't.
>>>>> Kent M Pitman writes:
KP> I program in order to improve my understanding of the world, not to
KP> achieve a goal. I pick goals that offer me interesing things to
KP> learn. Engaging in a practice whose goal was to divert me from any
KP> sense of personal satisfaction and any sense that I could construct
KP> and carry through a coherent throught experment without being derailed
KP> would not be satisfying to me. I'd change careers first.
Yes. XP *clearly* does not work for someone who programs with these
motivations. AND, I have NO problem with that. More power to you.
KP> But I know people who wouldn't.
I am such a person. I find tremendous satisfaction in being part of a
successful team, both at a technical _and_ commercial level. I'm not
willing to let abstract personal satisfaction in "cool" algorithms
detract me from implementing the simplest thing which can possibly
work and satisfy my customer's requirements. I know it may sound
terribly pedestrian, but, well, there you are.
When we have different goals, it is not surprising that we have
different means to best achieve those goals. I'm hoping that since
you now understand _my_ goals better, some of the things I've said may
make more sense to you in that context.
With this, I think I shall terminate my XP discussion, and let you all
get back to Lisp. :-)
--Alain Picard
--
It would be difficult to construe Larry Wall, in article
this as a feature. <·····················@netlabs.com>
Kent M Pitman <······@world.std.com> wrote:
+---------------
| Heh. I've often said this about language standards: that any one of
| us could design a better standard than us as a group, exactly because
| it would then have a single, coherent point of view and style. When
| we introduce democracy, or any consensus process other than simple
| dictatorship, we get weird combination effects that often are not what
| anyone wanted. SOMETIMES that's better, but often it's not...
+---------------
Reading this, I am struck by certain parallels that come up in the
design of contention-based network access protocols. Several decades
ago, people discovered that "asymmetrical" protocols [such as the
Urn Protocol, Kleinrock and Yemini (1978), or the Adaptive Tree Walk
Protocol, Capetanakis (1979)], where (subsets of) stations are treated
differently depending on recent behavior, can be much more efficient
than "symmetrical" protocols [such as Aloha, CSMA, or Ethernet], where
everyone is treated equally regardless of recent behavior.
In fact, while symmetric contention protocols may *look* fair, they
sometimes may be very *unfair* under certain conditions. For example,
the Ethernet protocol has a bug (sometimes known as the "capture effect"),
in which a station that has successfully transmitted recently has an
unfair advantage over stations that have lost the contention recently,
so much so that it can effectively "capture" the entire net for fairly
long periods of time. (Mart Molle's "BLAM" protocol fixes this, by
introducing a degree of history-based asymmetry into Ethernet CSMA/CD,
but AFAIK no Ethernet hardware manufacturer has implemented it.)
[Hmmm... There's some applicability to Lisp programming in there
*somewhere*... I think...]
-Rob
-----
Rob Warnock, 31-2-510 ····@sgi.com
SGI Network Engineering <URL:http://reality.sgi.com/rpw3/>
1600 Amphitheatre Pkwy. Phone: 650-933-1673
Mountain View, CA 94043 PP-ASEL-IA
>>>>> Jochen Schmidt writes:
Jochen> I have to say that I have no real experience with XP but my
Jochen> personal experience showed that this kind of working doesn't
Jochen> work very good. The problem _is_ that both people _may_ have
Jochen> an equally good idea - but often both ideas differ greatly in
Jochen> the basics. so it will happen that the watching person will
Jochen> constantly try to push the writer in his direction, which will
Jochen> then lead to an mix-solution that is really dirty when it
Jochen> works at all. IMHO sometimes it is more efficient to let
Jochen> people express their whole idea before trying to understand
Jochen> what they mean.
That can certainly be a problem. That is why it is helpful to have
some basic shared values. XP tries to promote these values:
* business value FIRST.
* Do the simplest thing that can possibly work
* refactor mercilessly
It's amazing how many deadlocks these can break, all by themselves.
The question always seems to boil down to: Should we do X, which
would take 30 minutes, or Y, which would take 60 and might help us
solve Z in the future?
The answer then is: Has customer asked us to solve Z? No? Let's do X.
Sounds silly, simplistic, shortsighted and counterintuitive, and yet
it works. This is the central insight (IMO) discovered by Kent Beck
and Ron Jeffries.
Of course, when there's a fundamental disagreement on a design, you
need to break ties in SOME manner, but in my experience, such
fundamental disagreement are the result of one party not understanding
something or not having access to some piece of information, and can
thus be eventually resolved to everybody's satisfaction, albeit with
much discussion.
--Alain Picard
--
It would be difficult to construe Larry Wall, in article
this as a feature. <·····················@netlabs.com>
Jochen Schmidt <···@dataheaven.de> wrote:
> I have to say that I have no real experience with XP but my personal
> experience showed that this kind of working doesn't work very good.
Sigh. Can you imagine what happened if someone wrote one of the
following sentences in this group:
"I have no real experience with Lisp, but my personal experience shows
that such a lot of parentheses don't work very good."
"I have no real experience with Lisp, but my personal experience shows
that dynamic typing is evil."
"I have no real experience with Lisp (only with Scheme), but my personal
experience shows that ..."
You get the drift.
It is fine, when people don't like XP and pair programming in particular
and if they don't want to do it. There's no need to back up this dislike
with any objective-looking reasons that aren't. I don't do XP or pair
programming and for the time being I think that it is not the way _I_
like to work. People I know who are doing XP tell me that it works very
well for them. Horses for courses.
Michael
--
Michael Schuerig
···············@acm.org
http://www.schuerig.de/michael/
········@acm.org (Michael Schuerig) writes:
> Sigh. Can you imagine what happened if someone wrote one of the
> following sentences in this group: [...]
Cross-posting invites the union of the people interested in a given topic,
not the intersection. When you broaden a discussion by inviting our whole
newsgroup, you invite unqualified commentary.
I directed my remarks only to comp.lang.lisp, not to their newsgroup.
My words were co-opted by Alain and re-presented out-of-appropriate context
and without my permission in just the way you describe, but not by my intent.
I don't doubt that people have discussions such as you describe about Lisp
elsewhere, free of someone to set them straight. I don't rove the nets
looking for such "injustices" to repair. But when it's dumped in my backyard
for discussion, the person doing the dumping should expect what comes.
I learned something through what they said. But newsgroups aren't a one-way
information device, and any of us is entitled to comment as well as listen.
Kent M Pitman <······@world.std.com> wrote:
> ········@acm.org (Michael Schuerig) writes:
>
> > Sigh. Can you imagine what happened if someone wrote one of the
> > following sentences in this group: [...]
>
> Cross-posting invites the union of the people interested in a given topic,
> not the intersection. When you broaden a discussion by inviting our whole
> newsgroup, you invite unqualified commentary.
Kent,
I wasn't commenting on any of your postings at all. I was replying to
Jochen Schmidt. Also, I'm a regular, though silent, reader of
comp.lang.lisp as well as comp.software.extreme-programming.
XP is being widely discussed for about two years now. In this time I
have read a sizable number of armchair reasons why it just can't work.
The matter is complicated by the fact that, of course, people don't put
forth these reasons frivolously. Thus, I don't doubt the sincerity of
Jochen's commentary, that in his experience something he takes to be
similar to XP doesn't work. The problem here is, that it is not at all
clear whether his particular experience is relevant for assessing XP.
> I don't doubt that people have discussions such as you describe about Lisp
> elsewhere, free of someone to set them straight. I don't rove the nets
> looking for such "injustices" to repair. But when it's dumped in my backyard
> for discussion, the person doing the dumping should expect what comes.
Apparently I failed to make my intention clear. My point was, that
independent of context, the argument was invalid.
> I learned something through what they said. But newsgroups aren't a one-way
> information device, and any of us is entitled to comment as well as listen.
Sure. The hard part is to judge for oneself what to make of a comment.
When I read one of your articles on Lisp, I take it as authoritative.
When I read what you write on XP, well, I take it as a personal comment
by someone who apparently doesn't know XP very well. And when I read
what you write about ways of developing software, then I think that I
like it better than I would like doing XP. Again, this is just personal
preference and doesn't say whether one way or another of doing software
development works better.
Michael
--
Michael Schuerig
···············@acm.org
http://www.schuerig.de/michael/
Michael Schuerig wrote:
> I wasn't commenting on any of your postings at all. I was replying to
> Jochen Schmidt. Also, I'm a regular, though silent, reader of
> comp.lang.lisp as well as comp.software.extreme-programming.
>
> XP is being widely discussed for about two years now. In this time I
> have read a sizable number of armchair reasons why it just can't work.
> The matter is complicated by the fact that, of course, people don't put
> forth these reasons frivolously. Thus, I don't doubt the sincerity of
> Jochen's commentary, that in his experience something he takes to be
> similar to XP doesn't work. The problem here is, that it is not at all
> clear whether his particular experience is relevant for assessing XP.
I want to make clear that I have not said that XP doesn't work. I've have
no practical experience with XP. What i've tried to say is that the
description of why pair-programming that the one I replied to posted is
against of what I experienced with working this way. I think that pair
programming is a good thing but not the way it was described.
Regards,
Jochen
>>>>> Kent M Pitman writes:
Kent> ········@acm.org (Michael Schuerig) writes:
Kent> Cross-posting invites the union of the people interested in a
Kent> given topic, not the intersection. When you broaden a
Kent> discussion by inviting our whole newsgroup, you invite
Kent> unqualified commentary.
Kent> I directed my remarks only to comp.lang.lisp, not to their
Kent> newsgroup. My words were co-opted by Alain and re-presented
Kent> out-of-appropriate context and without my permission in just the
Kent> way you describe, but not by my intent.
This is so sad. I redirected conversation to the XP newsgroups
precisely _because_ YOU, Kent, were making "unqualified commentary" about XP.
I've already noted several time that we're now off topic. So unless
you want to create comp.lang.lisp.extreme-programming.does-it-work,
you can either
a) be insular, and stay in this community, which has little first
hand experience with XP
b) stop talking about it
c) Let the XP guys know that the Lisp guys think XP is an
interesting approach, and how would it fit with lisp, etc etc.
Some lispers may wander over, some XPers may discover Lisp as a
suitable vehicale for XP (since some feel smalltalk is dying).
I'm happy with b) and c), but I think a) is a heads in the sand
approach.
Kent> out-of-appropriate context and without my permission in just the
At least you didn't say "misrepresented". Oh, also, I didn't realize
you needed "permission" to quote someone on usenet. Terribly sorry.
Well, I won't redirect to other groups anymore, as I've already given
pointers to look up for all those who are interested in discussion XP.
Kent, I wasn't trying to be obnoxious when I crossposted. Really.
But since you feel so strongly about it, I hereby promise to NEVER
quote you back in any forum other than the originating one.
Disclaimer-- I expect anyone to totally mangle anything I put in
writing on usenet in any forum whatever, which is why I never form
opinions on people based on "usenet hearsay".
--Alain Picard
--
It would be difficult to construe Larry Wall, in article
this as a feature. <·····················@netlabs.com>
Wow.
This whole thread was launched, inadvertently, when I answered
a simple question from Lieven: "did you consider telecommuting?"
and I answered "no". I did not make any value judgments on
telecommuting, except to say it does not work in OUR environment.
This is not the forum to discuss XP issues (Kent -- you removed the
cross post to the XP group. I'm adding it back). I don't really wish
to argue if XP is good or bad. We use it, we like it, end of
discussion. If you want to learn more about XP or argue why its bad
with people interested in arguing the point, follow up there. I'm NOT
interested in arguing such things, I'm interested in developing software.
That being said, I must address at least a few points, because I feel
a random observer passing by might get the wrong idea from your remarks.
>>>>> Kent M Pitman writes:
KP> If you both want to drive the same editor buffer, there may not be tools for
KP> that, but I bet the tools are not hugely better for people in the same room.
KP> And the only reason you wouldn't see it before would be failiure to invest
KP> in the obvious programmatic technology to support this so-called important
KP> activity.
KP> I guess my point being that if I had one-person boats and invented two-person
KP> boating, I'd expect to have to do some re-tooling before I could win. But
KP> somehow what I'm hearing suggests people are just blundering ahead with tools
KP> designed for a single person and then claiming it can only work locally.
KP> What a surprise.
Dear Kent,
I'm afraid you're missing the point. This is not too surprising, as I
haven't really made an attempt at describing what XP is and how we use
it. I would urge you to look this stuff up before jumping to
(erroneous) conclusions.
We don't NEED any new technology, we don't WANT any new technology.
Our primary value is communication, and I can communicate better by
talking to someone face to face than any other medium I know of.
I consider the task of entering the code into an editor an almost
trivial matter. For me, programming is the long argument about
design, algorithm, specification, desirability, etc etc which comes
*before* you enter any text into the emacs buffer. Once you've done
that, you've done 95% of the work. So having my partner kibitz and
point out my typos (or the other way 'round) is just gravy---the real
work of pair programming has already been done by the time we've come
to a mutual agreement as to what we're going to do next.
KP> Again, I'd rather type than speak a suggestion any day.
KP> I can do it much faster and with much greater precision.
I find that statement utterly amazing, and, if sincere, you are the
first person I've met for whom this holds. Look at this discussion
we're having now! If you and I were in a room, you'd already know
1000 times more about what we actually do than you do now, after a
week of written exchanges.
Humans have evolved language a long, long time, and I simply do not
believe that a written document can be superior to a one on one oral
argument in front of a white board. More durable, yes, permanent,
disseminable, etc, but those are not the attributes I look for as I
work with my partner. There, I want sheer communication bandwith.
KP> a good typist", and is dead easy to assure without having to be (as suggested
KP> in an earlier post) a "guru" or "god" or whatever other word people want to
KP> attach to certain programmers in order to dismiss them.
I'm sorry, but I find that almost offensive. Not only have I not
"dismissed" gurus and gods, I'd love to hire them. What I meant, and
I thought this was obvious, was that
1) programmers who can write an OS
for a Lisp Machine are few and far between,
2) I don't have any of them on my team, and
3) I have to deliver real products with the people I *do* have.
If I had a team of Gods and Gurus, (say, in R. Stallman's league), I'd
probably not be developing software the way I am now. I'm not
inflexible, nor dogmatic, I'm _pragmatic_, and I deal with things on a
case by case basis. I don't believe in silver bullets nor in "one
size fits all".
KP> [whole bunch of stuff on theory X/Y snipped...]
KP> You cannot simply decide that you will hire
KP> only one kind because you may misclassify them and it's certainly not
KP> grounds for firing if there is a reasonable management step you can
KP> take to get them to be working up to par. I Have to say I imagine the
KP> same is true of XP. It may well be that it's fun to have a whole shop
KP> full of one kind of person, but it sounds both discriminatory and
KP> short-sighted to me.
Well, if it's discriminatory to tell people what programming practices
we use, and ask them if they'd be willing to participate in those
practices, then we're being discriminatory. Needless to add, I find
that notion ludicrous and its implication offensive.
KP> Locking out someone who doesn't thrive
KP> in XP (or someone who does!) would seem inappropriate to best performance
KP> under this theory.
KP> JMO.
Well, thank you for your opinion, I guess, but the fact of the matter
is you've extrapolated way, way off the end of the curve from a few
meagre data points. I never said our work environment is perfect (it
isn't) or that XP works for everybody (it doesn't). I said that we
use it, we like it, and it makes telecommuting hard. Now I'm kinda
sorry I mentioned it at all, and it's certainly not germaine to
comp.lang.lisp anymore.
Alain Picard
--
It would be difficult to construe Larry Wall, in article
this as a feature. <·····················@netlabs.com>
Kent Pitman <······@world.std.com> writes:
| a good typist", and is dead easy to assure without having to be (as
| suggested in an earlier post) a "guru" or "god" or whatever other
| word people want to attach to certain programmers in order to
| dismiss them.
Alain Picard <·······@optushome.com.au> replies:
| I'm sorry, but I find that almost offensive. Not only have I not
| "dismissed" gurus and gods, I'd love to hire them. What I meant,
| and I thought this was obvious, was that
|
| 1) programmers who can write an OS
| for a Lisp Machine are few and far between,
| 2) I don't have any of them on my team, and
| 3) I have to deliver real products with the people I *do* have.
|
| If I had a team of Gods and Gurus, (say, in R. Stallman's league),
| I'd probably not be developing software the way I am now.
Actually, it seems to me that you _are_ dismissing "gurus" and "gods".
You say that arguments applying to Symbolics and Harlequin do not
apply to you, because their programmers were "gods", "gurus",
whatever. This seems to me like you are dismissing these programmers'
experiences and opinions.
Or, maybe, I have misunderstood you, I'm not sure.
Boris
--
·····@uncommon-sense.net - <http://www.uncommon-sense.net/>
You cannot achieve the impossible without attempting the absurd.
>>>>> Peter Wood writes:
>>
Peter> I completely fail to see how physical distance prevents you from
Peter> seeing the code and/or the entire team becoming familiar with the
Peter> entire code base.
Peter> There may be reasons xp won't work remotely but "writing code I never
Peter> get a chance to look" at is not one of them.
The key is in what does it mean to "get a chance to look" at the code.
If I'm sitting two feet away from you while you're typing and looking
at the same screen you are, I immediately see the code you type. If
you work remotely and check your changes in, I don't.
If my pair is sitting 3m away from your pair when we're trying to
understand something you wrote, we holler "hey, how's _this_ work?"
My voice doesn't carry 5000km and 10 timezones away. This slows us
down. We want to go fast.
Peter> ... fail to see how physical distance PREVENTS you from
Peter> seeing the code [snipped, and italics mine -- ap]
I didn't say it prevented me from seeing the code, I said I *WOULDN'T
HAVE A CHANCE* to see it. Verbatim:
[I wrote]
> this model does not scale to someone 5,000km away writing code
> I never get a chance to look at.
>
i.e. in order to see it, I'd have to do diffs, see what changed, etc
etc. This is all possible, but is NOT THE WAY WE LIKE TO WORK.
Post-facto code reviews may work, but it's not the XP way, and
its NOT THE WAY WE LIKE TO WORK. That's why physical distance
is a barrier.
Alain Picard
--
It would be difficult to construe Larry Wall, in article
this as a feature. <·····················@netlabs.com>
Alain Picard <·······@optushome.com.au> writes:
> The issues relating to code ownership are not issues of software
> source control, they are psychological issues that a programmer does
> not "own" the code that they wrote. So on our team, anyone of us
> feels completely free to modify any method, written by anyone else.
> We don't even go over to Joe and say "Hey, Joe, is it Okay if I
> change this method here to do X instead of Y?" We just do it.
How does this work for programmers with different levels of skill?
Beginner programmers often don't understand design issues. When they
need to change a piece of code, they often don't attempt to unedrstand
how the code was designed -- instead, they write a kludge that makes
the code "work" for the usage they can envision. With such a kludge,
even all the tests could pass, but the *design* can still be broken.
I know I'd hate to work in an environment where these kinds of things
happened. Does it happen in your team? If not, how do you prevent
it?
Hrvoje Niksic <·······@arsdigita.com> writes:
> How does this work for programmers with different levels of skill?
> Beginner programmers often don't understand design issues. When they
> need to change a piece of code, they often don't attempt to unedrstand
> how the code was designed -- instead, they write a kludge that makes
> the code "work" for the usage they can envision. With such a kludge,
> even all the tests could pass, but the *design* can still be broken.
>
*: Experienced programmers, on the other hand, understand that there was
no design. When they change a piece of code they often do not attempt
to understand how the code could be redesigned -- instead, they write
a kludge that makes the code work for the usage they can envison.
With such a kludge, all the tests will pass, and since the test suite
has been carefully thought through the system will satisfy the
customer's requirements, and ship on time. The design, if we can call
it that, is still broken, of course.
What you must fear is `designers'. These people will understand that
there was no design, and will sit down and create the most beautiful
design imaginable. This design will require a new programming
language, or possibly a complete new paradigm for its implementation.
The implementation of the design will take five years. After the
customer has bought the company out of bankruptcy, it will be
discovered that the design does not in fact solve the problem very
well, and relies on obscure properties of the machines it was
implemented on meaning it can never be generalised, and runs very
badly on more recent hardware. The customer's assets are bought out
of bankruptcy by Microsoft, who reimplement the system in Visual
Basic. GO TO *.
--tim
Tim Bradshaw <···@tfeb.org> writes:
> *: Experienced programmers, on the other hand, understand that there
> was no design. When they change a piece of code they often do not
> attempt to understand how the code could be redesigned -- instead,
> they write a kludge that makes the code work for the usage they can
> envison. With such a kludge, all the tests will pass, and since the
> test suite has been carefully thought through the system will
> satisfy the customer's requirements, and ship on time.
Has the test suite been thought out by the same "experienced
programmers" who don't think about design?
Hrvoje Niksic <·······@arsdigita.com> writes:
>
> Has the test suite been thought out by the same "experienced
> programmers" who don't think about design?
I didn't say they didn't think about design.
Hrvoje Niksic <·······@arsdigita.com> writes:
[ shared code-ownership ]
> How does this work for programmers with different levels of skill?
> Beginner programmers often don't understand design issues. When they
> need to change a piece of code, they often don't attempt to unedrstand
> how the code was designed -- instead, they write a kludge that makes
> the code "work" for the usage they can envision. With such a kludge,
> even all the tests could pass, but the *design* can still be broken.
>
> I know I'd hate to work in an environment where these kinds of things
> happened. Does it happen in your team? If not, how do you prevent
> it?
Given that they do pair-programming, and that one would usually pair
up beginners with more experienced programmers, the partner would be
expected to spot and prevent such approaches to problems.
Regs, Pierre.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
Alain Picard <·······@optushome.com.au> writes:
I didn't want to imply that it couldn't work. I did say that
when we tried it, the experiment was a failure. I would also
say that given our current style of development, I don't see
how we could successfully use remote collaboration. This is
actually very sad, as it limits our pool of potential
programmers.
perhaps you could hire a pair of people remotely?
thi
Alain Picard <·······@optushome.com.au> writes:
> The issues relating to code ownership are not issues of software
> source control, they are psychological issues that a programmer
> does not "own" the code that they wrote. So on our team, anyone
> of us feels completely free to modify any method, written by anyone
> else. We don't even go over to Joe and say "Hey, Joe, is it Okay
> if I change this method here to do X instead of Y?" We just do it.
Many shops which don't do XP or pair-programming have similar models
of non-exclusive code ownership, where module-teams or even whole
projects own the code collectively.
> We re-run all the tests, and if they pass, we commit the change.
> End of story. For this to work, we must all have a certain level
> of familiarity with the entire code base.
That's right.
> Clearly, this model does not scale to large teams, and clearly,
This I agree with, i.e with larger teams you usually have to divide
code-ownership into smaller sub-teams.
> this model does not scale to someone 5,000km away writing code
> I never get a chance to look at.
This I don't agree with, or rather I don't agree with the idea that
just because someone is sitting 5000 km away implies that you don't
get a chance to look at the code.
While pair-programming usually doesn't work remotely, the more
traditional techniques of code-reviews, etc. can often be done in a
more distributed fashion. While you lose the advantages
pair-programming gives you while actually writing the code/tests, the
other advantages (more than one-pair of eyes to spot problems, code
has to be written to be understandable by others, more than one person
that fully understands the code, etc.) still apply, IMHO.
Of course the danger with this is that since the code is already
written, people will be less than 100% motivated to do the code
inspections with the necessary level of commitment. That's always the
base problem with remote work, i.e. you have to do the additional work
that's needed to offset the lowered level of ad-hoc communication of
requirements, ideas, etc.
One way is e.g. to keep the granularity of the work-packets involved
low, so that each day new code/tests are reviewed, reworked and
checked-in as appropriate. That way there will be a constant level of
communication between collaborators, and hence less danger of
knowledge-drift.
You need an appropriate work-flow frame-work, so that all steps in the
process are fully automated, and can be initiated easily and often.
And you need to supervise people, so that there are no review-queue
stalls, etc.
Regs, Pierre.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
Alain Picard <·······@optushome.com.au> writes:
> The issues relating to code ownership are not issues of software
> source control, they are psychological issues that a programmer
> does not "own" the code that they wrote. So on our team, anyone
> of us feels completely free to modify any method, written by anyone
> else. We don't even go over to Joe and say "Hey, Joe, is it Okay
> if I change this method here to do X instead of Y?" We just do it.
> We re-run all the tests, and if they pass, we commit the change.
> End of story. For this to work, we must all have a certain level
> of familiarity with the entire code base.
>
> Clearly, this model does not scale to large teams, and clearly,
> this model does not scale to someone 5,000km away writing code
> I never get a chance to look at.
>
I completely fail to see how physical distance prevents you from
seeing the code and/or the entire team becoming familiar with the
entire code base. This is how Free software is developed all the
time.
There may be reasons xp won't work remotely but "writing code I never
get a chance to look" at is not one of them.
Code ownership is a matter of agreement among members of a team. A
programmer's proprietary feelings towards the code he's written are
not necessarily directly proportional to his *physical* distance from
others working on that code. I am sure you don't neglect to tell a new
"face-to-face" programmer about your team policies. Communication can
also take place electronically, believe it or not.
Peter
>>>>> Pierre R Mai writes:
Pierre> One way is e.g. to keep the granularity of the work-packets involved
Pierre> low, [SNIP]
Pierre> You need an appropriate work-flow frame-work, so that all steps in the
Pierre> process are fully automated, and can be initiated easily and often.
Pierre> And you need to supervise people, so that there are no review-queue
Pierre> stalls, etc.
Maybe. I'm not saying that wouldn't work, but I don't think it would
have the same feel as what we're doing now. It might be the best you
can do if you're _forced_ to have a distributed team.
Pierre> Of course the danger with this is that since the code is already
Pierre> written, people will be less than 100% motivated to do the code
Pierre> inspections with the necessary level of commitment.
That has universally been my experience in all (other) environments
I've worked in. Code reviews don't happen, or they're a lip-service
affair. Certainly, as reviewers, we never can 6 weeks of work and re
write the code, rather, we say "change this indentation here, that
method name there" and all feel good about ourselves. That obviously
sucks.
The environments in which code review ARE followed, e.g. military
environments (I have this from a colleague who worked on F15 aircraft
software) may work, but cost 1000 times more to deliver, and I would
find those a personal hell to work in. That obviously sucks.
The great thing about pair programming is the code review happens,
_naturally_ and without extra effort, at the _most critical_
moment---while it's being written. This has a tremendous positive
impact on quality.
Alain Picard
p.s. I find it fascinating that so many people in this group got
sparked off by this thread. It confirms one of my pet theories that
Lisp programmers are, on the whole, deeply commited to the quality
of their work. I encourage those who wish to know more about
this to peruse http://c2.com/cgi-bin/wiki?ExtremeProgrammingRoadmap.
--
It would be difficult to construe Larry Wall, in article
this as a feature. <·····················@netlabs.com>
[Replying to this one since you didn't add a lot of outsiders back.
Not planning to reply to the other one where you did.
http://world.std.com/~pitman/pfaq/cross-posting.html ]
Alain Picard <·······@optushome.com.au> writes:
> The great thing about pair programming is the code review happens,
> _naturally_ and without extra effort, at the _most critical_
> moment---while it's being written. This has a tremendous positive
> impact on quality.
Well, yes and no. I agree that this might be a positive in some regards, but
there is a second element of code review that is lost here: the necessity
of reconstructing a need for a cold reader. Certain classes of bugs are hard
to notice exactly because one is down and dirty in a certain way of thinking
and doesn't see the forest for the trees. Getting two people involved with
their noses pressed against trees doesn't guarantee avoiding such problems,
and if you're going to eliminate other code review because you think it was
done for you already, I'm not so sure that's a good idea.
> p.s. I find it fascinating that so many people in this group got
> sparked off by this thread. It confirms one of my pet theories that
> Lisp programmers are, on the whole, deeply commited to the quality
> of their work.
Well, it isn't all about sheer "quality". Lisp people are also commonly
interested in going meta on most topics, and in understanding the mechanics
of anything that has to do with process, since we model such things all
the time in our work. My interest in this is very little at the level of
"how I might improve the quality of my work" but much more at the level of
"how this might add to the set of patterns/paradigms I have for modeling
group behavior".
Further, it's common for Lisp people to take on tasks that usually take a
whole team of people in another language, and this often means they're
working on their own, I suspect. Which may be why they're curious about
anything that seems to require an extra person.
One thing that bugs me about this, btw, is that I still don't see how I could
ever build a piece of software that had this kind of "group mind" and feel
good about it. Most other processes (single worker, team projects,
hierarchies, etc.) work both for people and for program modules, so I can
share my knowledge of how people do these things into the computer world,
and vice versa. XP doesn't feel to me like it has any computational analog.
Can you suggest a case where I would ever connect two programs in this way?
I'm not saying there isn't such a way--I'm just not latching onto it right
away. It seems like it requires some shared notion of a "goodness metric" and
two individual generators for "plausibly good solutiosn" that can be quickly
tested for actual goodness by comparing goodness. That limits the space of
applicable domains quite a lot, it seems to me. It also vaguely feels to me
like it would be susceptible to hill-climbing problems, though that's just
a vague sense and I don't have a concrete case to elaborate why I think
that.
And Kent M Pitman writes:
-
- Can you suggest a case where I would ever connect two programs
- in this way?
Slipstreaming comes to mind...
http://www.tinker.ncsu.edu/ericro/slipstream/
You have two processes doing the same thing. One skips steps,
the other doesn't. The one skipping ahead shoots ideas about
what's going on towards the complete process. Speculative
predictions become much more accurate, and you get a overall
time-to-finish boost. Plus there are some fault-tolerance
uses.
In pair programming, I guess the typist could be the complete
process, and the other person could be mentally skipping ahead
in the task. The non-typist gives feedback to guide the typist.
Of course, you can generalize anything to the point where it
describes anything else, but...
Jason, who just wanted an excuse to point at slipstreaming...
--
Alain Picard <·······@optushome.com.au> writes:
> >>>>> Lieven Marchand writes:
>
>
> Lieven> Have you considered letting people stay where they are and
> Lieven> coordinating the work over mailinglists/internal newsgroups etc. with
> Lieven> only a few person to person meetings a year?
>
> No, not seriously. We do a lot of extreme programming, with a
> lot of emphasis on pair-programming.
I thought I recognised your name from another community. If you want
to do extreme programming, it's probably not ideal to try it
remotely. On the other hand, has extreme programming been tried with
teams larger than can be confortably housed on one office floor? Does
it scale to 200 person teams? There was some discussion of this on
Wiki but most of the XP'ers seem to have vanished from it.
--
Lieven Marchand <···@wyrd.be>
Gla�r ok reifr skyli gumna hverr, unz sinn b��r bana.
On 01 Mar 2001 21:49:49 +0100, Lieven Marchand <···@wyrd.be> wrote:
>On the other hand, has extreme programming been tried with
>teams larger than can be confortably housed on one office floor?
Not to my knowledge. Largest teams I know of are 40 programmers and
domain wizards, and 32 pprogrammers.
>Does
>it scale to 200 person teams?
Not without modification, I'd bet. Does CMM Level 5 scale down to
8-person teams? Not without modificartion, I'd bet. ;->
>There was some discussion of this on
>Wiki but most of the XP'ers seem to have vanished from it.
Right now there's a discussion of this on OTUG, and it's a perenniel
topic on the extremeprogramming mailing list on yahoo.
Ronald E Jeffries
http://www.XProgramming.com
http://www.objectmentor.com
Ron Jeffries <···········@acm.org> writes:
> Not without modification, I'd bet. Does CMM Level 5 scale down to
> 8-person teams? Not without modificartion, I'd bet. ;->
>
Easily. Since you need about 8 people to generate all the paperwork,
no software is ever written and no defects are ever found in it. ;-)
> Right now there's a discussion of this on OTUG, and it's a perenniel
> topic on the extremeprogramming mailing list on yahoo.
Guess I'll subscribe myself to yet another mailing list then. What's
OTUG?
--
Lieven Marchand <···@wyrd.be>
Gla�r ok reifr skyli gumna hverr, unz sinn b��r bana.