> 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".
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.
> 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.
> 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.
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?
> > 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.
> 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
[
«
|
12
]
Previous Topic
