Re: Just say no to threads [Was: Software architecture]

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.

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.

"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 
be 
that a 
have a 
>
> 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.

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.

"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 
the 
well 
>
> 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.

"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 wly 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.

"Cristiano Sadun" <cristianoTAKEun@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.
>
> 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.

Ronald E Jeffries <ronjeffries@acm.org> wrote in message news:<l41go0d2lqtkrbbl7hh97j1tj469
ltrj89@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

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

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.