ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Landis<>
Subject Re: OFFTOPIC! RE: IDEs vs. text editors, was RE: BorlandJbuilder f inally adds ant support (at a price)
Date Wed, 22 May 2002 13:44:29 GMT
Hi Paul,

Paul Hodgetts wrote:
> Sean Landis wrote:
> [Lots of good stuff about IDEs/JBuilder and Together...]
> Sean, right on, I agree totally with what you said, except for:
>  > That has a lot of value since the
>  > other requirement for agile is high team competency. Unfortunatly
>  > that doesn't scale beyond teams of a few.
> The "agile requires highly competent developers" is a myth.  *Any*
> development effort using *any* development process requires
> competent developers to avoid producing junk.  Can you name any
> process that works with low team competency and how it manages to
> produce good software?

You are right. Although I sense that agility suffers more for
lack of competence. All the processes and methodologies I've been 
exposed to require a fair amount skill to leverage. Unfortunately
so many organizations seem to think the purpose of these processes
and methods is to *avoid* the need for higher competence. Process
and method, in the right measure, applied by competent teams, is
a powerful tool for efficient, timely, and quality software development.

> I would argue that the highly collaborative nature of agile
> processes actually decreases this risk because the bad designs and
> code are discovered and repaired sooner, or caught before they
> even happen.  Collaboration also provides an environment for the
> more competent developers to mentor the less competent developers,
> or at least determine they are not mentorable and get them removed
> before they do damage.  Theoretically, you only need 50% of the
> developers to be reasonably competent and watch over the other
> half if collaboration is continuously practiced.

I agree totally. Sadly, so many organizations aren't even willing
to buck up for that first 50%. Then they declare process or
methodology failure instead of bothering to figure out what really
went wrong. 

> Agile processes *will* bring the incompetence to the fore very
> quickly.  The rapid drive to deliverables and high collaboration
> will force the incompetence to produce failure modes sooner and
> more visibly.  This is good, or at least much better than having
> the incompetence hide away for months and produce much more
> surprising and spectacular failure modes later on.

Which is a huge problem!

> I assume the scaling issue addresses the difficulty of staffing a
> larger team with good developers.  The problem is that incompetent
> developers produce drag on the team, and a team of four competent
> developers will usually perform better alone than they would if
> we added two incompetent developers to them.  My experience is
> that it's more productive and cost effective to slowly build a
> good team than to quickly build a bad one.  Again, not an agile
> problem, but a problem no matter what process.
> FWIW, I've coached and developed on four agile projects over the
> past two years, and we've had success with a mix of both junior
> and senior developers.  The truly incompetent developers were
> asked to work elsewhere.
> But, my apologies, this is an Ant list...

Oh, right ;-)

> Regards,
> Paul
> -----
> Paul Hodgetts -- Principal Consultant
> Agile Logic --
> Training, Mentoring, Development -- Agile Processes, XP, Java, J2EE, C++
> --
> To unsubscribe, e-mail:   <>
> For additional commands, e-mail: <>

View raw message