The Artima Developer Community
Sponsored Link

Java Community News
Scott Ambler on Agile Myths

21 replies on 2 pages. Most recent reply: Apr 26, 2007 11:26 PM by Isaac Gouy

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 21 replies on 2 pages [ « | 1 2 ]
Chris Agmen-Smith

Posts: 3
Nickname: agmenc
Registered: Feb, 2006

Re: Scott Ambler on Agile Myths Posted: Apr 26, 2007 8:26 AM
Reply to this message Reply
Advertisement
> Could a developer using a traditional, non-agile approach
> credibly claim that although their method doesn't require
> writing tests before code, their not anti-TDD because
> they'll do it if their customer wants to pay extra for
> it?

Having worked for a consultancy in a past life: yes.

I think comparing TDD to documentation is erroneous. TDD is a process, while (good) documentation is a deliverable.

Agile teams focus on the deliverables explicitly required by the business. On most projects, working software is the most important deliverable, usually accompanied by some degree of documentation, including user guides, developer/maintenance guides and an audit trail. Much of this might be captured in some online format, where it is more easily cross-referenced and kept up-to-date.

Traditional teams produce additional documentation as part of their development processes. First and foremost, this is often billed to the client as a separate activity. When I worked as a consultant, we would write documents for months before we'd do any code.

The traditional engagement model of consultancies, from which many industry practices arose, favours long, arduous, project life-cycles. And if you spend 6 month documenting business and architecture requirements, your client is obliged to approve the next statement of work, the one where you might deliver something useful, or else they'll look a little silly.

So documentation = billable activity.

As an aside, true Agile development makes for a poor consulting model. If your code is always ready to ship, right from your first release a few weeks into the project, then you can cut the consultants out of the loop at a moment's notice. If code ownership is shared, your staff can learn everything they need from the consultants, then give them the boot. And if you've only written required documentation, you'll be paid less.

It's a pity that "due diligence" is favoured as a selection mechanism when employing consultancies, rather than "quick and successful delivery of working systems".

Brad Schneider

Posts: 5
Nickname: snide
Registered: Jun, 2006

Re: Scott Ambler on Agile Myths Posted: Apr 26, 2007 9:04 AM
Reply to this message Reply
Correct me if I'm wrong, but didn't Eclipse originate from IBM's internal development group (the one that created several precursors under the VisualAge moniker). My understanding is that it was the next iteration of IBM's IDE platform and upon completion they then decided to open source it. My point is that it really isn't fair to use Eclipse as an example of distributed agile development if the core product was not developed using that model. Personally, I found Eclipse to be a little disappointing in general, so I'm not sure if I'd set that as the bar, but some people seem to think it's wonderful.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Scott Ambler on Agile Myths Posted: Apr 26, 2007 9:59 AM
Reply to this message Reply
> Correct me if I'm wrong, but didn't Eclipse originate from
> IBM's internal development group (the one that created
> several precursors under the VisualAge moniker). My
> understanding is that it was the next iteration of IBM's
> IDE platform and upon completion they then decided to open
> source it. My point is that it really isn't fair to use
> Eclipse as an example of distributed agile development if
> the core product was not developed using that model.

You have a point but the changes that the eclipse foundation have made are substantial.

> Personally, I found Eclipse to be a little disappointing
> g in general, so I'm not sure if I'd set that as the bar,
> but some people seem to think it's wonderful.

Most of the problems with Eclipse came out of the initial IBM development phase that you mention. Since it was open sourced, it has improved dramatically.

Jeff Ratcliff

Posts: 242
Nickname: jr1
Registered: Feb, 2006

Re: Scott Ambler on Agile Myths Posted: Apr 26, 2007 10:03 AM
Reply to this message Reply
> I think comparing TDD to documentation is erroneous. TDD
> is a process, while (good) documentation is a
> deliverable.
>

This is just playing with words. Documenting is a process that creates documents. TDD is a process that creates unit tests (albeit with an explicit ordering). In both cases, the development of code is influenced by the process being used, but not created by it. Most customers expect all relevent materials to be delivered, thus unit tests are just as much a deliverable as documentation.

Sebastian Kübeck

Posts: 44
Nickname: sebastiank
Registered: Sep, 2005

Re: Scott Ambler on Agile Myths Posted: Apr 26, 2007 11:09 AM
Reply to this message Reply
Alot of security people claim that agile methods cannot produce secure software.
Is it possible to produce software in shops that must adhere to security standards (SOX, PCI DSS etc.) and the bueraucracy therin using agile methods?

Erik Engbrecht

Posts: 210
Nickname: eengbrec
Registered: Apr, 2006

Re: Scott Ambler on Agile Myths Posted: Apr 26, 2007 3:21 PM
Reply to this message Reply
> > That's true. The bottom line is that we need the
> ability
> > to control the timing of development's completion, but
> no
> > one knows of a process which can provide that.
>
> That's easy. Set a completion date, collect the
> requirements and determine the resources. Then you create
> an arbitrary estimate that fits those constraints. But be
> proactive and pick out your patsies early so you won't be
> struggling to find someone to blame when you are put on
> the spot.

That's a rather cynical view. It is possible, but you need a disciplined organization with good historic data, realistic complexity estimates for new projects, and realistic assumptions about the resources available for executing the project (e.g. you can't assume all the best developers in the company will drop what they are doing and work your project, and that all hardware and software you need will magically appear).

Then you need balls-of-steel to defend these estimates.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: Scott Ambler on Agile Myths Posted: Apr 26, 2007 11:26 PM
Reply to this message Reply
James Watson wrote

> Maybe my current situation is not common but for some of
> our development approaches, we produce documentation that
> is almost as detailed as the code itself. ...
> The customers did not ask for this and could
> care less about it. We do it for ourselves.

You haven't said what this "documentation" is - what is it intended for?

(I've heard of people generating both functional spec documentation and working code from a spec fsm.)

Flat View: This topic has 21 replies on 2 pages [ « | 1  2 ]
Topic: Elliotte Rusty Harold on Type Inference for Java, and on Moving On Previous Topic   Next Topic Topic: Adobe to Open-Source Flex SDK

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use