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

From: David Lightstone (david._NoSpamlightstone_at_prodigy.net)
Date: 11/01/04 

Date: Mon, 01 Nov 2004 12:50:04 GMT

"Andrew McDonagh" <news@andrewcdonagh.f2s.com> wrote in message
news:cm3s6d$3n4$1@news.freedom2surf.net...
> Debbie Craft wrote:
> >
> > Kevin Cline wrote:
> >
> >> I've worked with a bunch of "done it before" telecom engineers,
> >> and mostly what that meant was that they were going to recapitulate
> >> the same workarounds they needed when developing for one-megahertz
> >> CPUs with 4MB of RAM even though they were now developing for a 500MHz
> >> CPUs with 1GB of RAM.
> >
> >
> > 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.
> >
> >
> > > Generally, for me, "done it before" is not a good reason to write
> > > code, although sometimes it can often be a good reason not to write
> > > code.
> >
> > 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.

Can you provide an example of a method/procedure/methodology that doesn't do
that?

>
> 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'.

So, its really not a software development problem. Its a business problem
(ie can't aford to provide the resources to do the job properly).

So what happens when they crank the productivity needs up a bit more. Any
chance XP will fail?

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