For Programmers: Free Programming Magazines  


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]
David Lightstone

2004-11-01, 8:55 am


"Andrew McDonagh" <news@andrewcdonagh.f2s.com> wrote in message
news:cm3s6d$3n4$1@news.freedom2surf.net...
> Debbie Craft wrote:
>
> 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.



Universe

2004-11-03, 3:56 am

Ronald E Jeffries <ronjeffries@acm.org> wrote:

> On Tue, 02 Nov 2004 12:59:17 GMT, "David Lightstone"
> <david._NoSpamlightstone@prodigy.net> wrote:
>
[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?


Both positions here incorrectly assume that circumstances where
individual developer positions called "Analyst", "Architect", and
"Designers" exist, necessarily means Waterfall is being used.

Please explain why as is true, that incremental/iterative development
can not be used where individual developer positions called "Analyst",
"Architect", and "Designers" exist.

Elliott
--
Theory Leads, Practice Verifies
Global Plans + Iterative/Incremental Development
Profiteer US Out of Iraq Now!
Sponsored Links







Also available: Server administration forum archive | Web Design forum archive | Software forum archive | Hardware reviews archive

Copyright 2008 codecomments.com