Home > Archive > Extreme Programming > November 2004 > Re: Just say no to threads [Was: Software architecture]
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Re: Just say no to threads [Was: Software architecture]
|
|
| Andrew McDonagh 2004-10-31, 8:55 pm |
| Debbie Craft wrote:
>
> Kevin Cline wrote:
>
>
>
> I have noticed this pattern a lot in XP. Something didn't work once so
> let's be afraid of that and never do it again. It's a particular
> animilastic response to your environment.
>
> You want to replace creating a more useful response with a process
> designed such that the behaviour isn't supposed to be possible. But of
> course the failings of these same people will reoccur at a different
> level because they have not changed.
>
>
>
> So for you it's always a mindless application of rules. Done it before
> -> do exactly the same thing.
>
> When you eat is it a new adventure everytime or do you apply knowledge
> you have used before?
>
> When you enter a new situation can you use your experience and adapt it
> to the current context without resorting to mindlessness? That is
> mindlessness in both directions: reapplication of what has been done
> before and the rule based application of a process.
>
> If i worked on the yahoo site or ebay and had been successful, when i go
> to a new situation i am just supposed to start all over again like a
> know nothing? Seems like an enormous waste to me. Dealing with scale and
> customers etc would have taught a lot of hard won lessons.
To me, it seems like some people seem to be
mis-understanding/interpreting what XPs YouAintGonnaNeedIt &
DoTheSimpliestThingThatCouldPossiblyWork
means.
Its not about checking your knowledge or brain in at the door when you
start work everyday on your XP project. We always uses the teams
collective knowledge gained over many mans years, to help solve the
development problem (i.e. the system) that the team is working on.
So, if we are working on the next Google site, and we worked on a
google-like site before, we'd use that knowledge to the fullest.
The difference with XP and the other agile processes over a lot of
non-agile Processes comes down to When that knowledge is used.
In years past, the larger could afford to take 3 years to develop (even
with monthly increments) a system, because it was the norm. However, in
todays markets, the competition is harder. This has meant a definite
change in business priority, to one of 'getting it out of the door'.
Now initially this resulted in a lot of systems getting out quickly,
only to make it back as quickly due to their high defect rates.
This is where the different Agile processes came in, in an attempt to
aid faster delivery of working systems. The differing processes manage
it in their own ways, but essentially they are all about satisfying the
immediate business requirements first, not the longer term ones, because
in todays markets, the system might not survive longer enough to get
those extra requirements.
| |
| Ronald E Jeffries 2004-11-02, 3:56 am |
| On Mon, 01 Nov 2004 17:17:54 GMT, "David Lightstone"
<david._NoSpamlightstone@prodigy.net> wrote:
>"Ronald E Jeffries" <ronjeffries@acm.org> wrote in message
> news:16pco094135tlaljj7227j24h707c2eqm4@
4ax.com...
>the
>
>Could you be more specific as to what you mean by a "bad" team? Seems that a
>"bad" team, is a strawman. Do you know of any employers that claim to have a
>"bad" team?
Ask CTips what he meant. I presume he meant a team that isn't very
good at developing software. No matter what employers may claim or
want, I have seen such teams. Have you never seen such a team?
--
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.
| |
| David Lightstone 2004-11-02, 8:56 am |
|
"Ronald E Jeffries" <ronjeffries@acm.org> wrote in message
news:8g1eo0tp4jvbprijo7rue7617b2r7uoroq@
4ax.com...
> On Mon, 01 Nov 2004 17:17:54 GMT, "David Lightstone"
> <david._NoSpamlightstone@prodigy.net> wrote:
>
iterative[color=darkred]
be[color=darkred]
that a[color=darkred]
have a[color=darkred]
>
> Ask CTips what he meant. I presume he meant a team that isn't very
> good at developing software. No matter what employers may claim or
> want, I have seen such teams. Have you never seen such a team?
The limitations in software development are imposed by the organization (at
a level above the project manager). They can destroy a good (whatever that
means) team, or make a bad (whatever that means) team look good
No I have never been on a bad team, I have been in bad organizations
(definitely not intended as an euphamism for bad team)
>
> --
> Ron Jeffries
> www.XProgramming.com
> I'm giving the best advice I have. You get to decide if it's true for you.
| |
| Ronald E Jeffries 2004-11-02, 8:55 pm |
| On Tue, 02 Nov 2004 12:59:17 GMT, "David Lightstone"
<david._NoSpamlightstone@prodigy.net> wrote:
>
>Pure waterfall is an idea. As an ideal it separates the two, no doubt about
>it. Now if you can only find me an organization that actually practices the
>ideal. There are and will be interactions between the tasks in the
>organizations that fail to achieve the ideal (pretty much all
>organizations).
>
>
>
>
>Of an organization that actually has separated the tasks sufficiently well
>so as to substanciate you claim
Are you seriously questioning whether there are organizations with
people designated as architects and designers? What color is the sky
on your planet?
--
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.
| |
| David Lightstone 2004-11-02, 8:55 pm |
|
"Ronald E Jeffries" <ronjeffries@acm.org> wrote in message
news:p61go0h13e21f31133bjif2ttdu9hk6lds@
4ax.com...
> On Tue, 02 Nov 2004 12:59:17 GMT, "David Lightstone"
> <david._NoSpamlightstone@prodigy.net> wrote:
>
about[color=darkred]
the[color=darkred]
well[color=darkred]
>
> Are you seriously questioning whether there are organizations with
> people designated as architects and designers? What color is the sky
> on your planet?
Having people designated as architects and having people designated as
designers does not imply that they do not influence each others thinking.
That can only happen when there is absolutely no contact between them. Such
would certainly not be the case in an organization that practices waterfall
as a methodology (there are reviews). I believe that is your claimed example
of a situation were it possibly could occur.
>
> --
> Ron Jeffries
> www.XProgramming.com
> I'm giving the best advice I have. You get to decide if it's true for you.
| |
| Cristiano Sadun 2004-11-03, 3:56 pm |
| "David Lightstone" <david._NoSpamlightstone@prodigy.net> wrote in
news:sLVhd.16085$0S6.13245@newssvr15.news.prodigy.com:
> Having people designated as architects and having people designated as
> designers does not imply that they do not influence each others thinking.
Hei David,
my $.1 is that, on average, on a group of more than a very few people
(placed very nearly to each other) explicit communication requires an
effort.
That's why you have all that w ly status meetings, monthly reports, etc.
It's often just simpler not to communicate. Not for any malicious intent,
but simply because everybody usually has more than enough burden try to
find out how to do things, or just simply doesn't think about it as
important, or simply don't like the kind of feelings public confrontation
on technical matters may bring.
| |
| David Lightstone 2004-11-03, 3:56 pm |
|
"Cristiano Sadun" <cristianoTAKE un@THIShotmailOUT.com> wrote in message
news:Xns9596A57CE6662Sadun@212.45.188.38...
> "David Lightstone" <david._NoSpamlightstone@prodigy.net> wrote in
> news:sLVhd.16085$0S6.13245@newssvr15.news.prodigy.com:
>
thinking.[color=darkred]
>
> Hei David,
>
> my $.1 is that, on average, on a group of more than a very few people
> (placed very nearly to each other) explicit communication requires an
> effort.
I agree effort is required.
The basic problem is the Ron contends that the communication never occurs,
that the development artifacts are simply thrown over the wall, with the
recipient being stuck with the situation. No doubt this can theoretically
occur (neither Ron nor I can identify an example of where and when it has
occured), but, and this is the issue of concern, when it occurs there is a
pathological problem present within the organization. The pathology implies
it doesn't matter what methodology is being used. The pathology itself
impeeds the successful operation of the methodology.
This makes "throw it over the wall" a strawman.
>
> That's why you have all that wly status meetings, monthly reports, etc.
>
I have always found meeting to be a big waste of time. You get 10 - 12
people in a room, all reporting "progress" and problems, but nobody really
understands enough (other then the project manager) to intuit things
> It's often just simpler not to communicate. Not for any malicious intent,
> but simply because everybody usually has more than enough burden try to
> find out how to do things, or just simply doesn't think about it as
> important, or simply don't like the kind of feelings public confrontation
> on technical matters may bring.
I consider this to be a serious problem, but it is not a methodology
problem.
| |
| Daniel Parker 2004-11-03, 8:56 pm |
| Ronald E Jeffries <ronjeffries@acm.org> wrote in message news:<l41go0d2lqtkrbbl7hh97j1tj469ltrj89@4ax.com>...
> On 2 Nov 2004 08:32:47 -0800, danielaparker@hotmail.com (Daniel
> Parker) wrote:
>
>
> Chief Operations Officer, the "customer" for this app. Sorry for the
> confusion.
Thanks. I understand it was the customer, but I didn't get the
acronym. I did a google search on COO and came up with
"kitschy-kitschy-coo", "coo-ee", "Coo-Coo" and divers others, but gave
up before coming to "Chief Operations Officer."
Daniel
| |
| Ilja Preuß 2004-11-03, 8:56 pm |
| Daniel Parker wrote:
> I did a google search on COO and came up with
> "kitschy-kitschy-coo", "coo-ee", "Coo-Coo" and divers others, but gave
> up before coming to "Chief Operations Officer."
http://www.acronymfinder.com/ is the "google for acronyms"... :)
Cheers, Ilja
| |
| Ronald E Jeffries 2004-11-04, 8:56 am |
| On Thu, 04 Nov 2004 00:55:04 GMT, "David Lightstone"
<david._NoSpamlightstone@prodigy.net> wrote:
>
>Trying to sneak one in eh Ron. How can you have phased and specialist job
>positions without a methodology?
Excuse me? You're the one with the three >> > chevrons up above,
arguing that poor communication is a serious problem, but not a
methodology problem. I'm agreeing that it's serious, and pointing out
that it /is/ a problem related to important aspects of methodology.
>
>Obviously we have had different experiences. I have attended "good"
>meetings, but they were still in my opinion a waste of time. The differing
>characteristic probably is equivalent to your usage of the term discipline.
>
>That is people prepared for the meeting rather than attended them. When a
>"status" survey was conducted it was completed prior to the meeting by the
>meeting leader and presented as a report (as such it was an integrated
>perspected, rather than dribbled factoids).
Fascinating. Let me see if I understand this. You would prefer
One person goes around to N people and finds out what they are
doing. Then he calls a meeting of the N people, and he tells them what
he remembers of what he heard that each is doing.
.... instead of ...
N people go to the meeting, and each one tells the group directly
what he is doing.
Am I correctly understanding your position?
--
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.
| |
| David Lightstone 2004-11-04, 8:56 am |
|
"Ronald E Jeffries" <ronjeffries@acm.org> wrote in message
news:fp0ko0ptutnjkq8f776jpl82mrchma5qn2@
4ax.com...
> On Thu, 04 Nov 2004 00:55:04 GMT, "David Lightstone"
> <david._NoSpamlightstone@prodigy.net> wrote:
>
>
> Excuse me? You're the one with the three >> > chevrons up above,
> arguing that poor communication is a serious problem, but not a
> methodology problem. I'm agreeing that it's serious, and pointing out
> that it /is/ a problem related to important aspects of methodology.
In this case you are correct. I misinterpreted the sentence "It can be
induced, exacerbated, or mitigated
by matters that do come under the purview of methodology, such as phases and
specialist job positions."
A lot of things are related, some directly, some obtusely. The impact of
phases and positions has an obtuse impact upon communication. So obtuse that
I consider it a - grasping at straws explination for the phenomena of poor
communication
>
differing[color=darkred]
discipline.[color=darkred]
the[color=darkred]
>
> Fascinating. Let me see if I understand this. You would prefer
>
> One person goes around to N people and finds out what they are
> doing. Then he calls a meeting of the N people, and he tells them what
> he remembers of what he heard that each is doing.
A meeting is a waste of time as I indicated initially. He just sends a
status report (same one he would write and send to his manager) to the 10 -
12 people he interviewed. This creates a nice tight feedback mechanism (as
I recall you are big on feedback mechanisms). More importantly not doing the
interviews might just be a waste of time. Do the math. Assume 10 minute
inteviews and 10 minutes to go from person to person vs a 30 minute staff
meeting (on the average everyone gets 5 min to speak up) The time to prepare
the status report is a common factor. (If you really want a meeting, assume
10 minutes for questions about the status report only)
>
> ... instead of ...
>
> N people go to the meeting, and each one tells the group directly
> what he is doing.
>
> Am I correctly understanding your position?
No see above and below
Collecting status that way does not achieve a consistent intuit of the
status for the group. This because each participant really pays attention to
the things that he/she can understand. The status will be preceived
differently by each participant. The team lead however does have to
synthesize a consensus (for a status report to his manager).
I am susprised that you have not previously observed this communication
problem. There is a rather famous Indian story that serves to illuminated
this specific communication problem. I'm sure you have heard it. You may
even have understoud it, but obviously not applied it (assuming that your
interpretation was done as an act of good faith). It begins with a number of
blind men attempting to describe an elephant. I'm sure you know the rest of
the story
>
> --
> Ron Jeffries
> www.XProgramming.com
> I'm giving the best advice I have. You get to decide if it's true for you.
| |
| David Lightstone 2004-11-04, 8:56 am |
|
"David Lightstone" <david._NoSpamlightstone@prodigy.net> wrote in message
news:S_pid.20125$0f6.11379@newssvr31.news.prodigy.com...
>
> "Ronald E Jeffries" <ronjeffries@acm.org> wrote in message
> news:fp0ko0ptutnjkq8f776jpl82mrchma5qn2@
4ax.com...
At some point the context was removed, the following serves to clearly
identify the serious problem that I do not consider to be a methodoliogy
problem. Perhaps Ron can expond on how it is induced, exacerbated or
mitigated by methodology considerations
[color=darkred]
intent,[color=darkred]
confrontation[color=darkred]
[color=darkred]
job[color=darkred]
>
> In this case you are correct. I misinterpreted the sentence "It can be
> induced, exacerbated, or mitigated
> by matters that do come under the purview of methodology, such as phases
and
> specialist job positions."
>
> A lot of things are related, some directly, some obtusely. The impact of
> phases and positions has an obtuse impact upon communication. So obtuse
that
> I consider it a - grasping at straws explination for the phenomena of poor
> communication
>
>
>
12[color=darkred]
discipline[color=darkred]
> differing
> discipline.
a[color=darkred]
> the
>
>
> A meeting is a waste of time as I indicated initially. He just sends a
> status report (same one he would write and send to his manager) to the
10 -
> 12 people he interviewed. This creates a nice tight feedback mechanism
(as
> I recall you are big on feedback mechanisms). More importantly not doing
the
> interviews might just be a waste of time. Do the math. Assume 10 minute
> inteviews and 10 minutes to go from person to person vs a 30 minute staff
> meeting (on the average everyone gets 5 min to speak up) The time to
prepare
> the status report is a common factor. (If you really want a meeting,
assume
> 10 minutes for questions about the status report only)
>
>
> No see above and below
>
> Collecting status that way does not achieve a consistent intuit of the
> status for the group. This because each participant really pays attention
to
> the things that he/she can understand. The status will be preceived
> differently by each participant. The team lead however does have to
> synthesize a consensus (for a status report to his manager).
>
> I am susprised that you have not previously observed this communication
> problem. There is a rather famous Indian story that serves to illuminated
> this specific communication problem. I'm sure you have heard it. You may
> even have understoud it, but obviously not applied it (assuming that your
> interpretation was done as an act of good faith). It begins with a number
of
> blind men attempting to describe an elephant. I'm sure you know the rest
of
> the story
>
you.[color=darkred]
>
>
|
|
|
|
|