The epistomology thread was nifty, but it departed from the issue
that seems more crucial: Are (test) documents useful or a waste of
time? When is a document a better "transport" than a conversation?
Never? Sometimes?
The XP hard line -- avoid documents, just talk -- is what I think
I'm hearing from Ron.
For me, this is an area where XP has overreacted. I definitely see a
place for (non-code) documents in an agile process. The essential
work of a sw development project is building knowledge, plus sharing
and distributing the knowledge effectively among all of the people
involved. (Subsequent to this, the application of that knowledge by
any individual is *relatively* straight-forward.) Documents work
because you can use them early (models that build knowledge),
because they persist (you're not crippled by your imperfect memory),
because they're efficient (you don't have to keep repeating the same
conversation with perfect fidelity), because they can capture
details (not just vague impressions), because they can be reviewed,
critiqued, and corrected (unlike your trembling thoughts), because
they remain (unlike you, you job-hopper!), etc.
I don't deny the real peril of over-documentation, which is why an
agile project ought to insist that all documents are purposeful,
i.e. contribute to the knowledge construction. Neither do I deny the
value of conversation in a small team nor do I claim that all
knowledge can or should be captured in a document.
The epistomology thread was nifty, but it departed from the issue that seems more crucial: Are (test) documents useful or a waste of time? When is a document a...
... Excellent points. Extreme programming demands this of the code as well as any documents the customer may require. -- Ward Cunningham 503-245-5633 v...
Ward Cunningham
ward@...
Dec 4, 2003 10:51 pm
... Agreed. But, in this thread, I'm interested in elaborating on the 2nd part of your response. You mention only documents that customers require. Do you mean...
... I would say that the only other documents that should be produced would be ones that the team wanted for some reason. I am using here a fairly broad...
... BRAVO!!!! Is it OK to assume you'd be OK with replacing "When" with "Under what circumstances," and would be willing to be more explicit about "better?"...
... Using conventional and I hope shared meanings of better ... A document might be better when ... communicating across distance although a phone call might...
... As programs get larger it becomes difficult to see them all at once. That makes it difficult to use the program itself as the basis of a conversation. I...
Ward Cunningham
ward@...
Dec 6, 2003 12:34 am
... Here's a little meta-commentary. I believe, certainly immodestly and quite possibly incorrectly, that I write more clearly than the average bear. And yet,...
... Have you ever read a project document and then talked to people on the project and realized that the document was missing a key fact? This happens a lot...
... Indeed ... in ... This is an argument for the point that there is knowledge that documents cannot and should not capture. But everyone agrees with that. I...
I read 2 things from this long email exchange: 1. change control and change management is required, also for documents 2. it takes a lot of writing to get a...
STEURS Stefan
stefan.steurs@...
Dec 5, 2003 2:44 pm
... It is an understatement to say 'great cost'. At one employer, I was assigned to work with a contract technical writer to create a developer's guide for...
... it, ... to ... places, ... one, ... each ... With all due respect I wouldn't necessarily blame the document. If the food tastes bad should we blame the...
... As I wrote, the document was created by a professional technical writer with my cooperation, (he interviewed me and I demonstrated) and was reviewed by...
... technical ... Agreed, that's also my experience. Especially for the most important documents, the "thinker-toys" that drive knowledge construction and that...
... This is essentially correct, but let me clarify one thing. I did not choose to use a tech writer. My manager contracted the tech writer and assigned us...
This seems an appropriate place for me to bring up an informal survey I started doing in my software testing classes recently. I ask participants to tell me,...
I encouraged Travis to post this question and I'm excited to see so many thought-provoking ideas on it. I like the idea of posting things for everyone to see,...
Hi Travis, You mention that you're a customer for the XP development team. It might help to think of the XP development team as your customer in this case....
... * assertion count per line of code added * count of "similar" lines (revealing some clonin' goin' on) Can we also go for a low cyclomatic complexity...
Branch/Node/Decision coverage analysis. Run tests Check the coverage of the code (Add tests for branches/paths/decisions not covered could be considered) I...
STEURS Stefan
stefan.steurs@...
Dec 2, 2003 3:11 pm
Overkill? If you have to recall a couple of million cell phones because of a stupid bug, overkill would be the last word you'd want to use. Everything should...
STEURS Stefan
stefan.steurs@...
Dec 2, 2003 3:11 pm
Can you please mail the test plan ? Thanks, Vikram ... ===== Thanks, Vikram __________________________________ Do you Yahoo!? Free Pop-Up Blocker - Get it now ...
Actually, if you are doing tdd, your unit tests should be giving you close to 100% statement coverage. If they don't, it's a sign that you aren't following...
Statement coverage is and will always remain rather insignificant to judge the quality of your code. It is better than no coverage at all, but it will tell...
STEURS Stefan
stefan.steurs@...
Dec 3, 2003 1:46 pm
... Bret's comment applies to lots of other types of coverage, I believe. I've made arguments to that effect for branch coverage, multiple condition coverage,...
We work with the customers to define actual key workflows that the customer must execute to perform their business operations. These workflows are a wider...