Practice: Shared Code

[Kent Beck]

Anyone on the team can improve any part of the system at any time. If
something is wrong with the system and fixing it is not out of scope for
what I'm doing right now, I should go ahead and fix it.

One objection I've heard is that if no one person is responsible for a
piece of code, then everyone will act irresponsibly. They will make
expedient changes, leaving a mess for the next person who has to touch the
code. The risk of this happening is why I've listed Shared Code as a
corollary practice. Until the team has developed a sense of collective
responsibility, no one is responsible and quality will deteriorate. People
will make changes without regard for the team-wide consequences.

There are other models of teamwork besides "every man for himself." The
team members can collectively assume responsibility not just for the quality
of what they deliver to users but also for the pride they take in their work
along the way. Pair programming helps teammates demonstrate their commitment
to quality to each other and helps them normalize their expectations for
what constitutes quality.

Continuous integration is another important prerequisite for collective
ownership. A two-hour programming session can touch many parts of the system
if there are many opportunities for improvement. Two pairs making many,
widespread changes increase the chance of expensive-to-resolve incompatible
changes. If the team is making lots of changes, it may want to reduce the
interval between integrations to keep the cost of integration down.

[Amir Kolsky]

I am a true believer in this practice, but it should be taken with a coupla'
pounds of salt. There are novices and there are experts. People should be
encouraged to reach beyond their grasp so that their hands will grow a bit
longer, but not at all costs.

If a novice decides to refactor the kernel of you product he can throw a
massive wrench in the works (two of them, it's a PP session, right?).

So, I recommend a sorta color coding scheme that paints various sections of
the code so that people with appropriate skills only will touch production
code. So you either have blue clearance or you don't (which is kinda fun in
a 24ish way).

1. I don't mean it literally. You don't have to use colors in the editor
(although the idea has some appeal).
2. Novices (in a certain area) should either experiment in a branch (and
then they can PP with other novices) - like a simulation, if you wish.
3. Novices will always have adult supervision when they muck with code that
they are not cleared for. I.e. they PP with someone who is cleared for that
color.

How do you get clearance?
1. You know when you're ready
2. You talk to the guy in charge (not *THE* guy in charge, this usually
leads to someone going up a water tower and CNN breaking news).

The reason I'm recommending this is because of accountability. The shared
code ownership does not mean that anyone can do anything. There's
accountability on programmers action, but it is sometimes better to let
people know what they should or shouldn't do.

Naturally, the place to deal with all this is the iteration planning and the
standup meeting.

(Hehe, I can imaging developers running around the place with a badge on
which small certification tokens are glued... Sorta like boy scouts, or
McDonalds... Yey! I got my French Fries certification.... Yey...)

Amir Kolsky
XP& Software



_____

From: Kent Beck [mailto:kentb-***@public.gmane.org]
Sent: Wednesday, April 13, 2005 8:36 AM
To: xpbookdiscussiongroup-***@public.gmane.org
Subject: [xpe2e] Practice: Shared Code


Anyone on the team can improve any part of the system at any time. If
something is wrong with the system and fixing it is not out of scope for
what I'm doing right now, I should go ahead and fix it.

One objection I've heard is that if no one person is responsible for a
piece of code, then everyone will act irresponsibly. They will make
expedient changes, leaving a mess for the next person who has to touch the
code. The risk of this happening is why I've listed Shared Code as a
corollary practice. Until the team has developed a sense of collective
responsibility, no one is responsible and quality will deteriorate. People
will make changes without regard for the team-wide consequences.

There are other models of teamwork besides "every man for himself." The
team members can collectively assume responsibility not just for the quality
of what they deliver to users but also for the pride they take in their work
along the way. Pair programming helps teammates demonstrate their commitment
to quality to each other and helps them normalize their expectations for
what constitutes quality.

Continuous integration is another important prerequisite for collective
ownership. A two-hour programming session can touch many parts of the system
if there are many opportunities for improvement. Two pairs making many,
widespread changes increase the chance of expensive-to-resolve incompatible
changes. If the team is making lots of changes, it may want to reduce the
interval between integrations to keep the cost of integration down.



_____

Yahoo! Groups Links


* To visit your group on the web, go to:
http://groups.yahoo.com/group/xpbookdiscussiongroup/


* To unsubscribe from this group, send an email to:
xpbookdiscussiongroup-unsubscribe-***@public.gmane.org
<mailto:xpbookdiscussiongroup-unsubscribe-***@public.gmane.org?subject=Unsubscrib
e>


* Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service
<http://docs.yahoo.com/info/terms/> .

[Ron Jeffries]

Post by Amir Kolsky
I am a true believer in this practice, but it should be taken with a coupla'
pounds of salt. There are novices and there are experts. People should be
encouraged to reach beyond their grasp so that their hands will grow a bit
longer, but not at all costs.
If a novice decides to refactor the kernel of you product he can throw a
massive wrench in the works (two of them, it's a PP session, right?).
So, I recommend a sorta color coding scheme that paints various sections of
the code so that people with appropriate skills only will touch production
code. So you either have blue clearance or you don't (which is kinda fun in
a 24ish way).

Amir,

I would be very interested to hear stories of teams working in XP
style where this rule was needed.

Though this is an interesting idea, I've not found it to be
necessary. When people are really working together as a team, pairs
rarely exceed their grasp and are quickly corrected in the few cases
where they do. Here are a few ideas about why that is the case:

A pair who are not qualified are not likely to be working alone on
the kernel, for two reasons: they aren't likely to be signed up
for a story on it, and the team's values are to have a qualified
pair when working on anything.

The tests show whether a kernel refactoring is "bad", and if they
don't, we have just discovered an opportunity for better testing.

At the standup meeting tomorrow, the pair will say "we refactored
the kernel," and anyone interested will inspect what they did and
work with them to correct it if it needs it.

Have you seen rampant refactoring to be an actual problem on an XP
team? I'd love to hear about it, and will want to be asking
questions about co-location, story focus and things like that.

Regards,

Ron Jeffries
www.XProgramming.com
The model that really matters is the one that people have in
their minds. All other models and documentation exist only to
get the right model into the right mind at the right time.
-- Paul Oldfield

[William Pietri]

Post by Amir Kolsky
If a novice decides to refactor the kernel of you product he can throw
a massive wrench in the works (two of them, it's a PP session,
right?).

Is this a hypothetical problem, or an actual one you've experienced? I'd
expect certain XP practices to make this unlikely, so I'd be especially
interested to hear details of when this happened in practice.

William

[Amir Kolsky]

I've seen cases where people undertook to change parts of the system that
they should not have touched. They tried to do their best but they ended up
botching up the job. Since we don't go about looking at every change to the
code - there are way too many of them, such changes went unnoticed until
they were, eh, noticed....

Amir Kolsky
XP& Software



_____

From: William Pietri [mailto:william-***@public.gmane.org]
Sent: Wednesday, April 13, 2005 8:31 PM
To: xpbookdiscussiongroup-***@public.gmane.org
Subject: RE: [xpe2e] Practice: Shared Code

Post by Amir Kolsky
If a novice decides to refactor the kernel of you product he can throw
a massive wrench in the works (two of them, it's a PP session,
right?).

Is this a hypothetical problem, or an actual one you've experienced? I'd
expect certain XP practices to make this unlikely, so I'd be especially
interested to hear details of when this happened in practice.

William
--
William Pietri <william-***@public.gmane.org>



_____

Yahoo! Groups Links


* To visit your group on the web, go to:
http://groups.yahoo.com/group/xpbookdiscussiongroup/


* To unsubscribe from this group, send an email to:
xpbookdiscussiongroup-unsubscribe-***@public.gmane.org
<mailto:xpbookdiscussiongroup-unsubscribe-***@public.gmane.org?subject=Unsubscrib
e>


* Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service
<http://docs.yahoo.com/info/terms/> .

[Ron Jeffries]

Post by Amir Kolsky
I've seen cases where people undertook to change parts of the system that
they should not have touched. They tried to do their best but they ended up
botching up the job. Since we don't go about looking at every change to the
code - there are way too many of them, such changes went unnoticed until
they were, eh, noticed....

I'm interested to hear more ...

Were these XP-style projects, with people working together, having
standup meetings every day where they say what they have done, and
such? Why did the tests not find these problems?

Ron Jeffries
www.XProgramming.com
Agility might be said to be about encountering
all the problems so early and so often that the
effort to fix them is less than the pain of enduring them.

[William Pietri]

Post by Amir Kolsky
I've seen cases where people undertook to change parts of the system
that they should not have touched. They tried to do their best but
they ended up botching up the job. Since we don't go about looking at
every change to the code - there are way too many of them, such
changes went unnoticed until they were, eh, noticed....

Interesting. Like others, I wonder why these cases didn't get caught in
the standup. But I'm also surprised they didn't get caught sooner.

In these cases, were the culprits pairing, and sitting close to the more
experienced developers? Also, were people switching pairs every few
hours? I'd also love to know what the code quality was like in the areas
that they touched, and roughly how much time had to be spent on cleanup.

Thanks,

William

[George Dinwiddie]

Post by Amir Kolsky
I've seen cases where people undertook to change parts of the system that
they should not have touched. They tried to do their best but they ended up
botching up the job. Since we don't go about looking at every change to the
code - there are way too many of them, such changes went unnoticed until
they were, eh, noticed....

While people are asking questions, what version control system were you
using? Was it difficult to identify and reverse their changes?

- George

[Amir Kolsky]

It was difficult due to the amount of code entered and the fact that others
built on that code.

Amir Kolsky
XP& Software



_____

From: George Dinwiddie [mailto:programminglists-***@public.gmane.org]
Sent: Thursday, April 14, 2005 4:39 AM
To: xpbookdiscussiongroup-***@public.gmane.org
Subject: Re: [xpe2e] Practice: Shared Code

Post by Amir Kolsky
I've seen cases where people undertook to change parts of the system that
they should not have touched. They tried to do their best but they ended up
botching up the job. Since we don't go about looking at every change to the
code - there are way too many of them, such changes went unnoticed until
they were, eh, noticed....

While people are asking questions, what version control system were you
using? Was it difficult to identify and reverse their changes?

- George
--
----------------------------------------------------------------------
When I remember bygone days George Dinwiddie
I think how evening follows morn; iDIA Computing, LLC
So many I loved were not yet dead, gdinwiddie-HLNzD44B1AikJOqCEYON2AC/***@public.gmane.org
So many I love were not yet born. http://www.idiacomputing.com
'The Middle' by Ogden Nash http://www.agilemaryland.org
----------------------------------------------------------------------





_____

Yahoo! Groups Links


* To visit your group on the web, go to:
http://groups.yahoo.com/group/xpbookdiscussiongroup/


* To unsubscribe from this group, send an email to:
xpbookdiscussiongroup-unsubscribe-***@public.gmane.org
<mailto:xpbookdiscussiongroup-unsubscribe-***@public.gmane.org?subject=Unsubscrib
e>


* Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service
<http://docs.yahoo.com/info/terms/> .

[George Dinwiddie]

And the others that built on that code didn't notice anything amiss with
the design?

- George

Post by Amir Kolsky
It was difficult due to the amount of code entered and the fact that others
built on that code.
Amir Kolsky
XP& Software
_____
Sent: Thursday, April 14, 2005 4:39 AM
Subject: Re: [xpe2e] Practice: Shared Code

Post by Amir Kolsky
I've seen cases where people undertook to change parts of the system that
they should not have touched. They tried to do their best but they ended

up

Post by Amir Kolsky
botching up the job. Since we don't go about looking at every change to

the

Post by Amir Kolsky
code - there are way too many of them, such changes went unnoticed until
they were, eh, noticed....

While people are asking questions, what version control system were you
using? Was it difficult to identify and reverse their changes?
- George

[Ron Jeffries]

Post by George Dinwiddie
And the others that built on that code didn't notice anything amiss with
the design?

Yeah ... I don't mean this in any disrespectful way to anyone, but
Amir's story doesn't sound to me like a reason to create a new
practice of redlining code, though I would think it prudent for any
team to make sure everyone knows where the swamps are. Amir's deal
sounds more to me like a team member who wasn't on board anyway. Am
I misreading things, Amir?

Ron Jeffries
www.XProgramming.com
How do I know what I think until I hear what I say? -- E M Forster

[Amir Kolsky]

I wasn't suggesting a per-se practice. I was just saying that practicing
Shared Code without understanding that it has its dangerous spots is not
prudent... Now, the problem is with those team members that are not totally
with the program. But, when you practice XP you're bound to have some people
who are not 100% on board. You need to be mindful of these.

Amir Kolsky
XP& Software



_____

From: xpbookdiscussiongroup-***@public.gmane.org
[mailto:xpbookdiscussiongroup-***@public.gmane.org] On Behalf Of Ron Jeffries
Sent: Saturday, April 16, 2005 1:28 AM
To: xpbookdiscussiongroup-***@public.gmane.org
Subject: Re: [xpe2e] Practice: Shared Code

Post by George Dinwiddie
And the others that built on that code didn't notice anything amiss with
the design?

Yeah ... I don't mean this in any disrespectful way to anyone, but
Amir's story doesn't sound to me like a reason to create a new
practice of redlining code, though I would think it prudent for any
team to make sure everyone knows where the swamps are. Amir's deal
sounds more to me like a team member who wasn't on board anyway. Am
I misreading things, Amir?

Ron Jeffries
www.XProgramming.com
How do I know what I think until I hear what I say? -- E M Forster




_____

Yahoo! Groups Links


* To visit your group on the web, go to:
http://groups.yahoo.com/group/xpbookdiscussiongroup/


* To unsubscribe from this group, send an email to:
xpbookdiscussiongroup-unsubscribe-***@public.gmane.org
<mailto:xpbookdiscussiongroup-unsubscribe-***@public.gmane.org?subject=Unsubscrib
e>


* Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service
<http://docs.yahoo.com/info/terms/> .

[Ron Jeffries]

Post by Amir Kolsky
I wasn't suggesting a per-se practice. I was just saying that practicing
Shared Code without understanding that it has its dangerous spots is not
prudent... Now, the problem is with those team members that are not totally
with the program. But, when you practice XP you're bound to have some people
who are not 100% on board. You need to be mindful of these.

Yes, agreed ... the team must do whatever it needs to to expose the
dangerous spots and ensure that they are dealt with appropriately,
by the right people. Over time, we hope they'll reduce the number of
such spots, and increase the number of such people.

Ron Jeffries
www.XProgramming.com
Example isn't another way to teach, it is the only way to teach.
--Albert Einstein

[Kent Beck]

Amir,

The way I practice shared code ownership, it does mean that anyone can do
anything. An individual might choose not to, but that is a personal choice,
not a law imposed from without.

I don't understand your reference to accountability. Can you explain more
about what you mean?

Kent Beck
Three Rivers Institute

From: Amir Kolsky [mailto:amir-***@public.gmane.org]
Sent: Wednesday, April 13, 2005 1:21 AM
To: xpbookdiscussiongroup-***@public.gmane.org
Subject: RE: [xpe2e] Practice: Shared Code

The reason I'm recommending this is because of accountability. The
shared code ownership does not mean that anyone can do anything. There's
accountability on programmers action, but it is sometimes better to let
people know what they should or shouldn't do.

[Dale Emery]

Hi Kent,

Post by Kent Beck
One objection I've heard is that if no one person is
responsible for a piece of code, then everyone will act
irresponsibly. They will make expedient changes, leaving a
mess for the next person who has to touch the code.

That's an example of a systems theory pattern called The Tragedy
of the Commons: If everybody is free to exploit a common
resource, and nobody is required to maintain it, then eventually
the resource will be spoiled.

Post by Kent Beck
There are other models of teamwork besides "every man for
himself." The team members can collectively assume
responsibility not just for the quality of what they deliver
to users but also for the pride they take in their work along
the way. Pair programming helps teammates demonstrate their
commitment to quality to each other and helps them normalize
their expectations for what constitutes quality.

I read a definition of accountability today that helps with that.
Patrick Lencioni, in his book Overcoming the Five Dysfunctions
of a Team, defines accountability as (something like) willingness
to challenge members of the community when they don't live up to
the community's standards.

Dale

[Joel Shellman]

Post by Dale Emery

Post by Kent Beck
One objection I've heard is that if no one person is
responsible for a piece of code, then everyone will act
irresponsibly. They will make expedient changes, leaving a
mess for the next person who has to touch the code.

This is lack of discipline/immaturity on the part of that/those
developers. That's a people issue and should be dealt with
appropriately. That said, consider that that would be a likely
scenario if the developer comes from a "traditional" background where
there is benefit to him/her to be lazy and sloppy. In XP, there
is/should be no benefit (personal or otherwise) to being lazy/sloppy
and developers have to get to the point where they understand that.
Often, at least for me, it can be a "Wow, I don't have to be an idiot
anymore!" kind of liberating experience.

Post by Dale Emery
That's an example of a systems theory pattern called The Tragedy
of the Commons: If everybody is free to exploit a common
resource, and nobody is required to maintain it, then eventually
the resource will be spoiled.

I would suggest this is different than the Commons, though. The
Commons refers to a limited resource that is used up. In source
code--all developers can own the entire resource (or a copy thereof).
I think the use of the term ownership is very important. It gives the
developer the feeling that they are a steward over this code--it's
their responsibility to cultivate it so it will become fruitful and
beautiful. Although they can destroy it for others (or rather, make it
very difficult for others), they won't gain any personal benefit from
doing so, so there should be far less motivation to do so, unlike the
Tragedy of the Commons. Also, a well implemented SCM system should
protect us.

However, I get the image of communal painting. Imagine Picasso and
Michelangelo standing at the same canvas ready to paint something
together. Hopefully, they can come together and do something
absolutely brilliant, but... And ego is as much a problem in this
industry as it is in art.

Joel Shellman
Mentics, Inc.

[Steven Gordon]

Was changing these parts of the system even in the scope of the stories these people were undertaking? If not, the story-based scope discipline is what needs to be enforced rather than segmenting the code base into separate fiefdoms.

Why were there not tests that failed as a result of these changes anyway?

It seems to me that you must be talking about an experience in a non-XP project.

-----Original Message-----
From: Amir Kolsky [mailto:amir-***@public.gmane.org]
Sent: Wednesday, April 13, 2005 12:58 PM
To: xpbookdiscussiongroup-***@public.gmane.org
Subject: RE: [xpe2e] Practice: Shared Code


I've seen cases where people undertook to change parts of the system that they should not have touched. They tried to do their best but they ended up botching up the job. Since we don't go about looking at every change to the code - there are way too many of them, such changes went unnoticed until they were, eh, noticed....

Amir Kolsky
XP& Software



_____

From: William Pietri [mailto:william-***@public.gmane.org]
Sent: Wednesday, April 13, 2005 8:31 PM
To: xpbookdiscussiongroup-***@public.gmane.org
Subject: RE: [xpe2e] Practice: Shared Code

Post by Amir Kolsky
If a novice decides to refactor the kernel of you product he can throw
a massive wrench in the works (two of them, it's a PP session,
right?).

Is this a hypothetical problem, or an actual one you've experienced? I'd
expect certain XP practices to make this unlikely, so I'd be especially
interested to hear details of when this happened in practice.

William

[Amir Kolsky]

It was a change (at least one of the cases) where the change was made in
order to implement some hardware support. That entailed chagned to parts of
the system's architecture. The code worked. The tests ran. The changes were
bad.

It's not that code should be segmented. It's that people should have a sense
of what they should or not should muck with. The problem is not with
experienced people. It's with the novices. You do not want them mucking
about with code that is important for them not to muck with. If they see
that some story that they are implementing is leading them into some
territory that they are not yet qualified to deal with, you'd like them to
know it so they can get assistance from someone who knows better...

Amir Kolsky
XP& Software



_____

From: Steven Gordon [mailto:sagordon-***@public.gmane.org]
Sent: Wednesday, April 13, 2005 9:11 PM
To: xpbookdiscussiongroup-***@public.gmane.org
Subject: RE: [xpe2e] Practice: Shared Code


Was changing these parts of the system even in the scope of the stories
these people were undertaking? If not, the story-based scope discipline is
what needs to be enforced rather than segmenting the code base into separate
fiefdoms.

Why were there not tests that failed as a result of these changes anyway?

It seems to me that you must be talking about an experience in a non-XP
project.

-----Original Message-----
From: Amir Kolsky [mailto:amir-***@public.gmane.org]
Sent: Wednesday, April 13, 2005 12:58 PM
To: xpbookdiscussiongroup-***@public.gmane.org
Subject: RE: [xpe2e] Practice: Shared Code


I've seen cases where people undertook to change parts of the system that
they should not have touched. They tried to do their best but they ended up
botching up the job. Since we don't go about looking at every change to the
code - there are way too many of them, such changes went unnoticed until
they were, eh, noticed....

Amir Kolsky
XP& Software



_____

From: William Pietri [mailto:william-***@public.gmane.org]
Sent: Wednesday, April 13, 2005 8:31 PM
To: xpbookdiscussiongroup-***@public.gmane.org
Subject: RE: [xpe2e] Practice: Shared Code

Post by Amir Kolsky
If a novice decides to refactor the kernel of you product he can throw
a massive wrench in the works (two of them, it's a PP session,
right?).

Is this a hypothetical problem, or an actual one you've experienced? I'd
expect certain XP practices to make this unlikely, so I'd be especially
interested to hear details of when this happened in practice.

William
--
William Pietri william-***@public.gmane.org





_____

Yahoo! Groups Links


* To visit your group on the web, go to:
http://groups.yahoo.com/group/xpbookdiscussiongroup/


* To unsubscribe from this group, send an email to:
xpbookdiscussiongroup-unsubscribe-***@public.gmane.org
<mailto:xpbookdiscussiongroup-unsubscribe-***@public.gmane.org?subject=Unsubscrib
e>


* Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service
<http://docs.yahoo.com/info/terms/> .

[Colin Putney]

Post by Amir Kolsky
It was a change (at least one of the cases) where the change was made in
order to implement some hardware support. That entailed chagned to parts
of the system's architecture. The code worked. The tests ran. The
changes were bad.

In what way were they bad?

Colin

[Amir Kolsky]

Bad design. Overly complex. Wrong pattern.

Amir Kolsky
XP& Software



_____

From: Colin Putney [mailto:cputney-63gG7TcDoKEsA/***@public.gmane.org]
Sent: Wednesday, April 13, 2005 10:11 PM
To: xpbookdiscussiongroup-***@public.gmane.org
Subject: Re: [xpe2e] Practice: Shared Code

Post by Amir Kolsky
It was a change (at least one of the cases) where the change was made in
order to implement some hardware support. That entailed chagned to parts
of the system's architecture. The code worked. The tests ran. The
changes were bad.

In what way were they bad?

Colin



_____

Yahoo! Groups Links


* To visit your group on the web, go to:
http://groups.yahoo.com/group/xpbookdiscussiongroup/


* To unsubscribe from this group, send an email to:
xpbookdiscussiongroup-unsubscribe-***@public.gmane.org
<mailto:xpbookdiscussiongroup-unsubscribe-***@public.gmane.org?subject=Unsubscrib
e>


* Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service
<http://docs.yahoo.com/info/terms/> .

[Colin Putney]

Post by Amir Kolsky
Bad design. Overly complex. Wrong pattern.

Yup, that's bad.

I'm curious though, why you want to address the by putting certain parts
of the code base off limits to novices. Are certain areas more
susceptible to bad design? Are they a bad match for certain novices
limited experience?

To put it another way, what's wrong with some more experience pair
coming along later, noticing the bad design and fixing it? That's the
way it works in the "novice allowed" areas, right?

Colin

[Jim Shore]

Post by Amir Kolsky
It was a change (at least one of the cases) where the change was made in
order to implement some hardware support. That entailed chagned to parts
of the system's architecture. The code worked. The tests ran. The
changes were bad.

How much effort did it take to improve the code afterwards?

Jim

[Amir Kolsky]

A lot, some of it not recovered till today... Mind you, as an XP project it
was not run by the book... First project for client, they know better...

Accountability - the girl who was in charge of the mess was eventually let
go.

Amir Kolsky
XP& Software



_____

From: Jim Shore [mailto:jshore-***@public.gmane.org]
Sent: Thursday, April 14, 2005 1:23 AM
To: xpbookdiscussiongroup-***@public.gmane.org
Subject: Re: [xpe2e] Practice: Shared Code

Post by Amir Kolsky
It was a change (at least one of the cases) where the change was made in
order to implement some hardware support. That entailed chagned to parts
of the system's architecture. The code worked. The tests ran. The
changes were bad.

How much effort did it take to improve the code afterwards?

Jim
--
James Shore - Titanium I.T. LLC - Successful Software
See my new website and blog: http://www.jamesshore.com

phone: [phone]
email: jshore-***@public.gmane.org


_____

Yahoo! Groups Links


* To visit your group on the web, go to:
http://groups.yahoo.com/group/xpbookdiscussiongroup/


* To unsubscribe from this group, send an email to:
xpbookdiscussiongroup-unsubscribe-***@public.gmane.org
<mailto:xpbookdiscussiongroup-unsubscribe-***@public.gmane.org?subject=Unsubscrib
e>


* Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service
<http://docs.yahoo.com/info/terms/> .

[Kent Beck]

Amir,

I understand the story to be that someone made changes where they weren't
qualified, the problems compounded, when they were finally discovered they
were difficult to fix, and finally the person who made the changes was
fired. When you say "girl", I get the impression the person making the
changes was a junior programmer. If the "girl" ignored warnings or hid her
activities or didn't ask for help when she really should have known she
needed it, the firing seems like a reasonable consequence for her actions.
If she was just in over her head and someone else should have known better,
then firing her is not an example of accountability but scapegoating.
Scapegoating minimizes the chances the people actually responsible for the
mistake will learn from their actions and sends a crazy-making message to
the rest of the team. I would like to know more about the circumstances of
the story, if you can share them.

Kent Beck
Three Rivers Institute


_____

From: Amir Kolsky [mailto:amir-***@public.gmane.org]
Sent: Wednesday, April 13, 2005 11:40 PM
To: xpbookdiscussiongroup-***@public.gmane.org
Subject: RE: [xpe2e] Practice: Shared Code


A lot, some of it not recovered till today... Mind you, as an XP project it
was not run by the book... First project for client, they know better...

Accountability - the girl who was in charge of the mess was eventually let
go.

Amir Kolsky
XP& Software



_____

From: Jim Shore [mailto:jshore-***@public.gmane.org]
Sent: Thursday, April 14, 2005 1:23 AM
To: xpbookdiscussiongroup-***@public.gmane.org
Subject: Re: [xpe2e] Practice: Shared Code

Post by Amir Kolsky
It was a change (at least one of the cases) where the change was made in
order to implement some hardware support. That entailed chagned to parts
of the system's architecture. The code worked. The tests ran. The
changes were bad.

How much effort did it take to improve the code afterwards?

Jim
--
James Shore - Titanium I.T. LLC - Successful Software
See my new website and blog: http://www.jamesshore.com

phone: [phone]
email: jshore-***@public.gmane.org


_____

Yahoo! Groups Links


* To visit your group on the web, go to:
http://groups.yahoo.com/group/xpbookdiscussiongroup/


* To unsubscribe from this group, send an email to:
xpbookdiscussiongroup-unsubscribe-***@public.gmane.org
<mailto:xpbookdiscussiongroup-unsubscribe-***@public.gmane.org?subject=Unsubscrib
e>


* Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service
<http://docs.yahoo.com/info/terms/> .

[Steven Gordon]

The changes were bad in terms of style and/or complexity rather than functionality? Or an experienced developer would have seen how to leverage the existing objects without modifying them?

I recall something about whenever anyone asks for help, the team provides it (not sure whether this is part of xpe2e). Mandating that a pair asks for help when getting beyond their experience or understanding might be a more constructive way to address this problem than placing explicit limitations on the shared code practice. This also might be more general in that there could be activities other than refactoring existing code that novices could mess up a project doing if they do not ask for help.

-----Original Message-----
From: Amir Kolsky [mailto:amir-***@public.gmane.org]
Sent: Wednesday, April 13, 2005 2:00 PM
To: xpbookdiscussiongroup-***@public.gmane.org
Subject: RE: [xpe2e] Practice: Shared Code


It was a change (at least one of the cases) where the change was made in order to implement some hardware support. That entailed chagned to parts of the system's architecture. The code worked. The tests ran. The changes were bad.

It's not that code should be segmented. It's that people should have a sense of what they should or not should muck with. The problem is not with experienced people. It's with the novices. You do not want them mucking about with code that is important for them not to muck with. If they see that some story that they are implementing is leading them into some territory that they are not yet qualified to deal with, you'd like them to know it so they can get assistance from someone who knows better...

Amir Kolsky
XP& Software



_____

From: Steven Gordon [mailto:sagordon-***@public.gmane.org]
Sent: Wednesday, April 13, 2005 9:11 PM
To: xpbookdiscussiongroup-***@public.gmane.org
Subject: RE: [xpe2e] Practice: Shared Code


Was changing these parts of the system even in the scope of the stories these people were undertaking? If not, the story-based scope discipline is what needs to be enforced rather than segmenting the code base into separate fiefdoms.

Why were there not tests that failed as a result of these changes anyway?

It seems to me that you must be talking about an experience in a non-XP project.

-----Original Message-----
From: Amir Kolsky [mailto:amir-***@public.gmane.org]
Sent: Wednesday, April 13, 2005 12:58 PM
To: xpbookdiscussiongroup-***@public.gmane.org
Subject: RE: [xpe2e] Practice: Shared Code


I've seen cases where people undertook to change parts of the system that they should not have touched. They tried to do their best but they ended up botching up the job. Since we don't go about looking at every change to the code - there are way too many of them, such changes went unnoticed until they were, eh, noticed....

Amir Kolsky
XP& Software



_____

From: William Pietri [mailto:william-***@public.gmane.org]
Sent: Wednesday, April 13, 2005 8:31 PM
To: xpbookdiscussiongroup-***@public.gmane.org
Subject: RE: [xpe2e] Practice: Shared Code

Post by Amir Kolsky
If a novice decides to refactor the kernel of you product he can throw
a massive wrench in the works (two of them, it's a PP session,
right?).

Is this a hypothetical problem, or an actual one you've experienced? I'd
expect certain XP practices to make this unlikely, so I'd be especially
interested to hear details of when this happened in practice.

William

[Amir Kolsky]

That's the point of the coloring... Make people aware that there are areas
where they should ask for help. You could let them have a go at it an fail,
but it might cost you later on. So, let your novices know that there are
areas where they should ask for help.

If the tests pass, the functionality is preserved. It's the complexity that
is usually the novice's pitfall.

Amir Kolsky
XP& Software



_____

From: Steven Gordon [mailto:sagordon-***@public.gmane.org]
Sent: Wednesday, April 13, 2005 10:15 PM
To: xpbookdiscussiongroup-***@public.gmane.org
Subject: RE: [xpe2e] Practice: Shared Code


The changes were bad in terms of style and/or complexity rather than
functionality? Or an experienced developer would have seen how to leverage
the existing objects without modifying them?

I recall something about whenever anyone asks for help, the team provides it
(not sure whether this is part of xpe2e). Mandating that a pair asks for
help when getting beyond their experience or understanding might be a more
constructive way to address this problem than placing explicit limitations
on the shared code practice. This also might be more general in that there
could be activities other than refactoring existing code that novices could
mess up a project doing if they do not ask for help.

-----Original Message-----
From: Amir Kolsky [mailto:amir-***@public.gmane.org]
Sent: Wednesday, April 13, 2005 2:00 PM
To: xpbookdiscussiongroup-***@public.gmane.org
Subject: RE: [xpe2e] Practice: Shared Code


It was a change (at least one of the cases) where the change was made in
order to implement some hardware support. That entailed chagned to parts of
the system's architecture. The code worked. The tests ran. The changes were
bad.

It's not that code should be segmented. It's that people should have a sense
of what they should or not should muck with. The problem is not with
experienced people. It's with the novices. You do not want them mucking
about with code that is important for them not to muck with. If they see
that some story that they are implementing is leading them into some
territory that they are not yet qualified to deal with, you'd like them to
know it so they can get assistance from someone who knows better...

Amir Kolsky
XP& Software



_____

From: Steven Gordon [mailto:sagordon-***@public.gmane.org]
Sent: Wednesday, April 13, 2005 9:11 PM
To: xpbookdiscussiongroup-***@public.gmane.org
Subject: RE: [xpe2e] Practice: Shared Code


Was changing these parts of the system even in the scope of the stories
these people were undertaking? If not, the story-based scope discipline is
what needs to be enforced rather than segmenting the code base into separate
fiefdoms.

Why were there not tests that failed as a result of these changes anyway?

It seems to me that you must be talking about an experience in a non-XP
project.

-----Original Message-----
From: Amir Kolsky [mailto:amir-***@public.gmane.org]
Sent: Wednesday, April 13, 2005 12:58 PM
To: xpbookdiscussiongroup-***@public.gmane.org
Subject: RE: [xpe2e] Practice: Shared Code


I've seen cases where people undertook to change parts of the system that
they should not have touched. They tried to do their best but they ended up
botching up the job. Since we don't go about looking at every change to the
code - there are way too many of them, such changes went unnoticed until
they were, eh, noticed....

Amir Kolsky
XP& Software



_____

From: William Pietri [mailto:william-***@public.gmane.org]
Sent: Wednesday, April 13, 2005 8:31 PM
To: xpbookdiscussiongroup-***@public.gmane.org
Subject: RE: [xpe2e] Practice: Shared Code

Post by Amir Kolsky
If a novice decides to refactor the kernel of you product he can throw
a massive wrench in the works (two of them, it's a PP session,
right?).

Is this a hypothetical problem, or an actual one you've experienced? I'd
expect certain XP practices to make this unlikely, so I'd be especially
interested to hear details of when this happened in practice.

William
--
William Pietri william-***@public.gmane.org






_____

Yahoo! Groups Links


* To visit your group on the web, go to:
http://groups.yahoo.com/group/xpbookdiscussiongroup/


* To unsubscribe from this group, send an email to:
xpbookdiscussiongroup-unsubscribe-***@public.gmane.org
<mailto:xpbookdiscussiongroup-unsubscribe-***@public.gmane.org?subject=Unsubscrib
e>


* Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service
<http://docs.yahoo.com/info/terms/> .

[Ron Jeffries]

Post by Amir Kolsky
That's the point of the coloring... Make people aware that there are areas
where they should ask for help. You could let them have a go at it an fail,
but it might cost you later on. So, let your novices know that there are
areas where they should ask for help.
If the tests pass, the functionality is preserved. It's the complexity that
is usually the novice's pitfall.

Netting this all down, I have a sense that while this would be an
interesting idea, it may be covering up some kind of communication
problem. I'd expect the issue to have been detected at the standup
meeting, for example, for the pair to have been overheard in the
workroom, etc.

If the code worked but was excessively complex, not much harm done.
If it actually didn't work, then I'd wonder where the test was.

It remains an interesting idea, but I just get a scent that I don't
quite like ...

Ron Jeffries
www.XProgramming.com
Inigo Montoya: You are wonderful!
Man in Black: Thank you. I have worked hard to become so.

[William E Caputo]

Post by Ron Jeffries
Netting this all down, I have a sense that while this would be an
interesting idea, it may be covering up some kind of communication
problem.

Or perhaps it solved a communication problem. Would we say that Pair
programming is covering up some kind of communication problem?

Best,
Bill

William E. Caputo
ThoughtWorks, Inc.
http://www.williamcaputo.com
--------
omnis cellula e cellula

[Ron Jeffries]

Post by William E Caputo

Post by Ron Jeffries
Netting this all down, I have a sense that while this would be an
interesting idea, it may be covering up some kind of communication
problem.

Or perhaps it solved a communication problem. Would we say that Pair
programming is covering up some kind of communication problem?

No, I don't think we would.

In the case of "newbies" working where they shouldn't, however, I'd
wonder why open workspace, comprehensive tests, stand up meetings,
and all that other good stuff, wouldn't have prevented the problem
or solved it promptly.

So while coloring dangerous code red might address the specific
issue, I was concerned that there might be something underlying it,
and was inclined to dig a bit to find out.

Probably I'm out of line with that concern, and this may not be the
right forum anyway.

Ron Jeffries
www.XProgramming.com
Show me the features!

[George Dinwiddie]

So while coloring dangerous code red ...

Hmmm... I wonder who's going to maintain the coloring? And how do you
test that the appropriate code is colored?

Even in a non-XP project, I would think that someone might notice the
changes when they did an update. Unless it's a real death march, I tend
to glance at changes most of the time just to keep track of what's
happening in the rest of the system.

- George

[Amir Kolsky]

Incidentally, the project is not a death march.

You don't really color... It was a metaphor....

Amir Kolsky
XP& Software



_____

From: George Dinwiddie [mailto:programminglists-***@public.gmane.org]
Sent: Thursday, April 14, 2005 4:46 AM
To: xpbookdiscussiongroup-***@public.gmane.org
Subject: Re: [xpe2e] Practice: Shared Code

So while coloring dangerous code red ...

Hmmm... I wonder who's going to maintain the coloring? And how do you
test that the appropriate code is colored?

Even in a non-XP project, I would think that someone might notice the
changes when they did an update. Unless it's a real death march, I tend
to glance at changes most of the time just to keep track of what's
happening in the rest of the system.

- George
--
----------------------------------------------------------------------
When I remember bygone days George Dinwiddie
I think how evening follows morn; iDIA Computing, LLC
So many I loved were not yet dead, gdinwiddie-HLNzD44B1AikJOqCEYON2AC/***@public.gmane.org
So many I love were not yet born. http://www.idiacomputing.com
'The Middle' by Ogden Nash http://www.agilemaryland.org
----------------------------------------------------------------------





_____

Yahoo! Groups Links


* To visit your group on the web, go to:
http://groups.yahoo.com/group/xpbookdiscussiongroup/


* To unsubscribe from this group, send an email to:
xpbookdiscussiongroup-unsubscribe-***@public.gmane.org
<mailto:xpbookdiscussiongroup-unsubscribe-***@public.gmane.org?subject=Unsubscrib
e>


* Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service
<http://docs.yahoo.com/info/terms/> .

[George Dinwiddie]

Yes, but who is going to make sure that all of the appropriate code is
marked as "high difficulty"? How will you know that you've marked the
code appropriately?

Post by Amir Kolsky
Incidentally, the project is not a death march.
You don't really color... It was a metaphor....
Amir Kolsky
XP& Software
_____
Sent: Thursday, April 14, 2005 4:46 AM
Subject: Re: [xpe2e] Practice: Shared Code

So while coloring dangerous code red ...

Hmmm... I wonder who's going to maintain the coloring? And how do you
test that the appropriate code is colored?
Even in a non-XP project, I would think that someone might notice the
changes when they did an update. Unless it's a real death march, I tend
to glance at changes most of the time just to keep track of what's
happening in the rest of the system.
- George

[Ron Jeffries]

Post by George Dinwiddie
Yes, but who is going to make sure that all of the appropriate code is
marked as "high difficulty"? How will you know that you've marked the
code appropriately?

Well, when low difficulty people modify it, they'll mess it up? :)

Ron Jeffries
www.XProgramming.com
Speculation or experimentation - which is more likely to give the correct answer?

[George Dinwiddie]

Post by Ron Jeffries

Post by George Dinwiddie
Yes, but who is going to make sure that all of the appropriate code is
marked as "high difficulty"? How will you know that you've marked the
code appropriately?

Well, when low difficulty people modify it, they'll mess it up? :)

Ah! So what happened was an appropriate test. Too bad they deleted
that test. ;-)

[Steven Gordon]

Again, designating which parts of the code novices should stay away from waters down the principle of shared code and does not even address the general problem.

The general problem is that everyone (not just novices) need to know to ask for help when they are in dangerous territory (not just in pre-existing code that somebody decides to designate as off-limits). Furthermore, why should novices be able to overcomplicate other parts of the code base?

The code-coloring suggestion is symptomatic of the brute-force solutions to specific instances of more general problems that quickly accumulate to create heavy software development processes that inhibit our agility as well as the ability for novices to grow into experts.

-----Original Message-----
From: Amir Kolsky [mailto:amir-***@public.gmane.org]
Sent: Wednesday, April 13, 2005 2:26 PM
To: xpbookdiscussiongroup-***@public.gmane.org
Subject: RE: [xpe2e] Practice: Shared Code


That's the point of the coloring... Make people aware that there are areas where they should ask for help. You could let them have a go at it an fail, but it might cost you later on. So, let your novices know that there are areas where they should ask for help.

If the tests pass, the functionality is preserved. It's the complexity that is usually the novice's pitfall.

Amir Kolsky
XP& Software



_____

From: Steven Gordon [mailto:sagordon-***@public.gmane.org]
Sent: Wednesday, April 13, 2005 10:15 PM
To: xpbookdiscussiongroup-***@public.gmane.org
Subject: RE: [xpe2e] Practice: Shared Code


The changes were bad in terms of style and/or complexity rather than functionality? Or an experienced developer would have seen how to leverage the existing objects without modifying them?

I recall something about whenever anyone asks for help, the team provides it (not sure whether this is part of xpe2e). Mandating that a pair asks for help when getting beyond their experience or understanding might be a more constructive way to address this problem than placing explicit limitations on the shared code practice. This also might be more general in that there could be activities other than refactoring existing code that novices could mess up a project doing if they do not ask for help.

-----Original Message-----
From: Amir Kolsky [mailto:amir-***@public.gmane.org]
Sent: Wednesday, April 13, 2005 2:00 PM
To: xpbookdiscussiongroup-***@public.gmane.org
Subject: RE: [xpe2e] Practice: Shared Code


It was a change (at least one of the cases) where the change was made in order to implement some hardware support. That entailed chagned to parts of the system's architecture. The code worked. The tests ran. The changes were bad.

It's not that code should be segmented. It's that people should have a sense of what they should or not should muck with. The problem is not with experienced people. It's with the novices. You do not want them mucking about with code that is important for them not to muck with. If they see that some story that they are implementing is leading them into some territory that they are not yet qualified to deal with, you'd like them to know it so they can get assistance from someone who knows better...

Amir Kolsky
XP& Software



_____

From: Steven Gordon [mailto:sagordon-***@public.gmane.org]
Sent: Wednesday, April 13, 2005 9:11 PM
To: xpbookdiscussiongroup-***@public.gmane.org
Subject: RE: [xpe2e] Practice: Shared Code


Was changing these parts of the system even in the scope of the stories these people were undertaking? If not, the story-based scope discipline is what needs to be enforced rather than segmenting the code base into separate fiefdoms.

Why were there not tests that failed as a result of these changes anyway?

It seems to me that you must be talking about an experience in a non-XP project.

-----Original Message-----
From: Amir Kolsky [mailto:amir-***@public.gmane.org]
Sent: Wednesday, April 13, 2005 12:58 PM
To: xpbookdiscussiongroup-***@public.gmane.org
Subject: RE: [xpe2e] Practice: Shared Code


I've seen cases where people undertook to change parts of the system that they should not have touched. They tried to do their best but they ended up botching up the job. Since we don't go about looking at every change to the code - there are way too many of them, such changes went unnoticed until they were, eh, noticed....

Amir Kolsky
XP& Software



_____

From: William Pietri [mailto:william-***@public.gmane.org]
Sent: Wednesday, April 13, 2005 8:31 PM
To: xpbookdiscussiongroup-***@public.gmane.org
Subject: RE: [xpe2e] Practice: Shared Code

Post by Amir Kolsky
If a novice decides to refactor the kernel of you product he can throw
a massive wrench in the works (two of them, it's a PP session,
right?).

Is this a hypothetical problem, or an actual one you've experienced? I'd
expect certain XP practices to make this unlikely, so I'd be especially
interested to hear details of when this happened in practice.

William

[Amir Kolsky]

I would like to clarify my position here.

I am not saying that people should be disallowed from doing things on stuff
they don't fully understand. I'm saying that it would be useful, for both
the organization and the individual developer to know their limits and to
have assistance in figuring out where and when they should seek help. As it
turns out, developers, especially novices, are notoriously difficult at
saying "I need help here". Once it's easy for them to say that, they are no
longer novices...

Programming actions have repercussions. You need to know what you are doing
and what the repercussions are. If you really foul up something you could
get fired. If you do something good you get lauded. That's accountability.
Now, we can assist newbies, as I've said before, in figuring out where they
need to seek help - in the iteration plan, in the standup, in the room. I do
not assume that anyone can do anything. It may not be in the organizations
best interest to have anyone do everything. So, if a novice is venturing
into dangerous territory they and their bosses should be aware of it.

Amir Kolsky
XP& Software



_____

From: Kent Beck [mailto:kentb-***@public.gmane.org]
Sent: Thursday, April 14, 2005 6:00 AM
To: xpbookdiscussiongroup-***@public.gmane.org
Subject: RE: [xpe2e] Practice: Shared Code


Amir,

The way I practice shared code ownership, it does mean that anyone can do
anything. An individual might choose not to, but that is a personal choice,
not a law imposed from without.

I don't understand your reference to accountability. Can you explain more
about what you mean?

Kent Beck
Three Rivers Institute

From: Amir Kolsky [mailto:amir-***@public.gmane.org]
Sent: Wednesday, April 13, 2005 1:21 AM
To: xpbookdiscussiongroup-***@public.gmane.org
Subject: RE: [xpe2e] Practice: Shared Code

The reason I'm recommending this is because of accountability. The
shared code ownership does not mean that anyone can do anything. There's
accountability on programmers action, but it is sometimes better to let
people know what they should or shouldn't do.



_____

Yahoo! Groups Links


* To visit your group on the web, go to:
http://groups.yahoo.com/group/xpbookdiscussiongroup/


* To unsubscribe from this group, send an email to:
xpbookdiscussiongroup-unsubscribe-***@public.gmane.org
<mailto:xpbookdiscussiongroup-unsubscribe-***@public.gmane.org?subject=Unsubscrib
e>


* Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service
<http://docs.yahoo.com/info/terms/> .

[Ron Jeffries]

Amir,

I can support this recasting of your position pretty strongly. I'd
like to pull out and touch on a few items. As I touch, I'll try to
make clear where my support is, and where my remaining concerns lie.

Post by Amir Kolsky
I would like to clarify my position here.
I am not saying that people should be disallowed from doing things on stuff
they don't fully understand. I'm saying that it would be useful, for both
the organization and the individual developer to know their limits and to
have assistance in figuring out where and when they should seek help. As it
turns out, developers, especially novices, are notoriously difficult at
saying "I need help here". Once it's easy for them to say that, they are no
longer novices...

I agree that it's valuable for people to understand their
limitations, and that some signposts of some kind could be valuable.

Certainly having the ability to say we need help might be part of
maturity: I'm not sure I'd really say it makes us not novices any
more, but that's a quibble.

Post by Amir Kolsky
Programming actions have repercussions. You need to know what you are doing
and what the repercussions are.

Yes. Close communication and good testing provide important feedback
on that. A "simple" instruction to novices might be useful, such as:

Before you work on code you haven't worked on before, please call
out and ask whether you should go in alone. There are parts of the
system that are, unfortunately, tricky and not well surrounded by
tests. Going in there alone could be deadly. So please always ask.

Post by Amir Kolsky
If you really foul up something you could
get fired. If you do something good you get lauded. That's accountability.

I'm not sure that's accountability, but I think that's a separate
topic.

Post by Amir Kolsky
Now, we can assist newbies, as I've said before, in figuring out where they
need to seek help - in the iteration plan, in the standup, in the room.

Yes, we can. I took you to be suggesting redlining the code and
saying that some people can't go there, but your example made me
wonder why existing XP mechanisms wouldn't have handled the
situation. It sounds like the project wasn't as "XP" as it might
have been, so my conclusion is that it's a topic worth being alert
to, but that I wouldn't add redlining as a general practice.

Post by Amir Kolsky
I do
not assume that anyone can do anything. It may not be in the organizations
best interest to have anyone do everything. So, if a novice is venturing
into dangerous territory they and their bosses should be aware of it.

I take the shared code practice to mean that anyone MAY do anything
(as a pair, one hopes), and I think that a recent posting by Kent
makes clear that he really means that. I know that I really mean it.

I do not believe that anyone CAN, at any moment do anything. That
is, we are not all ABLE to accomplish any goal right here right now.
So there are things that a person is permitted to do, which she
is unable to do. That's the definition of dangerous territory,
perhaps.

And I agree ... individuals and the team should know when people are
venturing into territory that is dangerous for them. It might not be
just a novice thing. Some territory might be dangerous for the most
experienced person on the team. In any case, the team should know.

The question becomes ... what are good ways to know? Thanks for
raising the topic.

Ron Jeffries
www.XProgramming.com
To Fly, Flip Away Backhanded -- Master Frisbee

[Amir Kolsky]

She insisted on scaffolding much more than she needed to despite continued
hints and statements of discontent from coaches and managers. I consider it
a personal failure that I coudn't get her to play ball with the rest.

Amir Kolsky
XP& Software



_____

From: Kent Beck [mailto:kentb-***@public.gmane.org]
Sent: Thursday, April 14, 2005 9:02 PM
To: xpbookdiscussiongroup-***@public.gmane.org
Subject: RE: [xpe2e] Practice: Shared Code


Amir,

I understand the story to be that someone made changes where they weren't
qualified, the problems compounded, when they were finally discovered they
were difficult to fix, and finally the person who made the changes was
fired. When you say "girl", I get the impression the person making the
changes was a junior programmer. If the "girl" ignored warnings or hid her
activities or didn't ask for help when she really should have known she
needed it, the firing seems like a reasonable consequence for her actions.
If she was just in over her head and someone else should have known better,
then firing her is not an example of accountability but scapegoating.
Scapegoating minimizes the chances the people actually responsible for the
mistake will learn from their actions and sends a crazy-making message to
the rest of the team. I would like to know more about the circumstances of
the story, if you can share them.

Kent Beck
Three Rivers Institute


_____

From: Amir Kolsky [mailto:amir-***@public.gmane.org]
Sent: Wednesday, April 13, 2005 11:40 PM
To: xpbookdiscussiongroup-***@public.gmane.org
Subject: RE: [xpe2e] Practice: Shared Code


A lot, some of it not recovered till today... Mind you, as an XP project it
was not run by the book... First project for client, they know better...

Accountability - the girl who was in charge of the mess was eventually let
go.

Amir Kolsky
XP& Software



_____

From: Jim Shore [mailto:jshore-***@public.gmane.org]
Sent: Thursday, April 14, 2005 1:23 AM
To: xpbookdiscussiongroup-***@public.gmane.org
Subject: Re: [xpe2e] Practice: Shared Code

Post by Amir Kolsky
It was a change (at least one of the cases) where the change was made in
order to implement some hardware support. That entailed chagned to parts
of the system's architecture. The code worked. The tests ran. The
changes were bad.

How much effort did it take to improve the code afterwards?

Jim
--
James Shore - Titanium I.T. LLC - Successful Software
See my new website and blog: http://www.jamesshore.com

phone: [phone]
email: jshore-***@public.gmane.org




_____

Yahoo! Groups Links


* To visit your group on the web, go to:
http://groups.yahoo.com/group/xpbookdiscussiongroup/


* To unsubscribe from this group, send an email to:
xpbookdiscussiongroup-unsubscribe-***@public.gmane.org
<mailto:xpbookdiscussiongroup-unsubscribe-***@public.gmane.org?subject=Unsubscrib
e>


* Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service
<http://docs.yahoo.com/info/terms/> .

[Tim King]

Post by Amir Kolsky
Accountability - the girl who was in charge of the mess was
eventually let go...
She insisted on scaffolding much more than she needed to despite
continued hints and statements of discontent from coaches and
managers. I consider it a personal failure that I coudn't get her to
play ball with the rest.

Unfortunately, sometimes people indeed don't fit in with the team. If
she truly didn't fit, she probably was the first to realize this and
perhaps was already looking for another job.

However, this seems to me a completely seperate issue. How does this
apply to shared code? The team produces the design. If a single
developer through her own young-headedness was able to derail the whole
team's efforts, it seems that's a problem with your process, not a
problem with her. Now, there may also have been a problem with her. But
you'll always have young developers, and even experienced people will
make mistakes, sometimes quite big mistakes. There's nothing any of us
can do about that.

Moreover, any problem big enough to be noticed by so many people is big
enough to be the partial responsibility of more than one person. If you
start assigning blame, developers will stop taking initiative. The team
will blind itself to the real results of their development process, for
fear of being blamed. It won't be able to reflect honestly and improve
its process as long as it allows any one person to be blamed for
something the team produced. To assign blame is counter-productive. Each
member of the team must feel safe enough to take initiative when need
be. And the team as a whole must feel safe enough to reflect honestly on
the failure (or success) in order to improve its process.

In fact-- Since this is the Extreme Programming list, I guess I can say
something a little extreme. Under no circumstances is it acceptable to
assign blame (or credit) for the failure (or success) of a project or
any part of a project. Because the responsibility for the project's
success or failure is the team's.

So, my question: Is shared code, then, an extreme instance of team
responsibility and accountablity? Is shared code a variation on periodic
reflection, applied with as short a period as possible? If any pair can
break a piece of code, any pair can fix it. Then, don't developers need
to feel safe enough to inspect, critique, and refactor the design, not
just during formal reflection, but in even shorter cycles, on an ongoing
basis? And as a corrolary, since all team members share responsibility
for the code, doesn't that mean they each have a responsibility to
maintain the design and to offer constructive criticism to other team
members?

-TimK