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

From: Kevin Cline (kevin.cline_at_gmail.com)
Date: 11/03/04 

Date: 3 Nov 2004 09:35:23 -0800

"Shayne Wissler" <thalesNOSPAM000@yahoo.com> wrote in message news:<Jnbhd.339104$MQ5.314635@attbi_s52>...
> "Debbie Craft" <d145@yahoo.com> wrote in message
> news:10oa0ghfqur5fad@news.supernews.com...
> >
> > 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.
>
> Indeed.
>
> > 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.
>
> True - but in XP it doesn't matter if you, as an individual, know anything.
> What matters in XP is that the team understand and agree. And in order for
> them to do that, you have to reduce everything to the lowest common
> denominator.

I don't agree with this assessment. Pair programming exposes all team
members to the practices of the others. The team develops a consensus
best practice that is better than any of them were practicing
individually.

In my experience, other methodologies allow developers to do as they
please as long as superficial coding standards are met and acceptance
tests pass. Higher level measures of code quality, such as module
cohesion, coupling, complexity, and duplication are often not
recognized formally as a defect requiring rework. This isolates
low-performing team members from the practices of others, and
insulates them from valid criticism.

By contrast, XP explicitly values simplicity and promotes the
elimination of duplication, and that promotes high code quality.
Since code is owned by the team, developers will see others improve
their work, and hopefully will learn from the experience.

Relevant Pages

  • Re: xp and simple design
    ... I think the focus should not be "What practices do we ... Good developers need ... > agile have almost all moved very close to XP. ... Well that depends on the manager. ...
    (comp.object)
  • Re: About method comments
    ... If the technical staff all say waterfall process is best practice, ... planning that the developers were forced to shoulder. ... practices associated with XP and say those practices obviate the need ...
    (comp.lang.smalltalk)
  • Re: What is the alternative to lack of C++ style "const" in C#
    ... practical application of const in C++, the fact that you can just cast it ... > Other developers feel you should build your own protection. ... > The last option is, screw it, and don't worry about it. ... > What is your thoughts and practices? ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Newbie question on code vetting
    ... I know this is not a particularly fascinating topic for developers, ... was more transparency with respect to the practices observed within the ... committers across projects. ... With regard to the issue of trust, how can I either trust or decide not to ...
    (comp.lang.python)
  • Re: Building SQL query when table is two words...
    ... >> practices in code writing/database creation rather than ones which ... >>> developers are often fixing up someone else's work and don't have the ... >>> Bradley ... >>> A Christian Response ...
    (comp.databases.ms-access)