There is, but it doesn't change anything, because you're still providing absolutely no evidence to support the claim. And it's still a good example of blaming people being "lazy" for a thing without any evidence. Just-world fallacy; insisting that all the problems are caused by people behaving badly, who therefore somehow deserve it.

I don't know if anyone associated with this project adopted anything they called "agile" or not. What I was saying was that I have zero confidence in "agile" as I've seen it either defined or applied, for products that are (a) large, (b) complex and/or (c) have substantial infrastructure (versus user-facing) functionality. This project had at least (a) large, and probably (c) substantial infrastructure requirements (that might have been solvable by judicious selection of the right commercial products.)

It should be a feature that a waterfall project could be seen to fail early, but for the PM whose career is built on continuing the project past his tenure, there's no advantage to her/him to fail quickly.

Yeah, I know what the allegation is. Where's the evidence? Where's the clinical studies?

People love to assert that someone with a cognitive disability isn't really disabled, just "lazy". But that people enjoy asserting it doesn't make it true.

I'd be interested in the basis for the claim about misdiagnosis being "common". I have known a number of people with ADHD who were misdiagnosed with something else. I don't think I've ever met anyone who got a misdiagnosis of not having ADHD.

The quality of the anti-ADHD-diagnosis rants can be pretty much summed up by the fact that people are claiming that a stimulant drug which makes people twitchy is going to "drug people into zombified submission". It really is that blatantly stupid; there is nothing remotely like "zombified submission" on the table.

Kool-aid...

I'm not defending the F-35 (I'm a huge A-10 fan, and 2 F-35s would fund the whole A-10 fleet), but your comment here is self-contradictory. Either we don't need it, OR it's trying to fill too many missions (that do need to be done.)

I think it's the latter, and that's not just requirements creep, but a different phenomenon that is something like "requirements conbinatorics", where too many requirements get loaded onto a system (health care or weapon) and the result is either (a) not buildable as a violation of math or physics or (b) massively complex and therefore massively expensive.

It's a combination of no discipline on the part of the users/managers who develop the specifications or needs statement, and the problem that the number of major system starts (whether DoD or commercial) is limited, so each user/stakeholder needs to get -His/Her Requirement- in place on this system, because they won't have a chance for another 10 years to get that requirement into their/their user's hands.

dave

PLEASE Mod Parent up! I've been working on large government funded systems (defense and commercial) for 35+ years, and in my view programs are screwed from the beginning by overly-aggressive schedules for the up-front work. When the incomplete/absent requirements/architecture/design results in coding, or more often test and integration delays, they'll find more money and time. By then, it's too late.

Back when we had explicit waterfall milestones (requirements review, preliminary design review, etc), we could tell at PDR a program would fail as a result of incomplete or even incorrect requirements & architecture.

Unfortunately, the adoption of "Agile" in these organizations has reinforced the culture of "We don't need no stinking requirements! We can draw an architecture on a whiteboard in an afternoon", resulting in systems where you really can't say anything intelligent about how long it will take to complete them, because you have no fscking idea what "complete" actually is.

And this -should not be a revelation-, at least to anyone who has read "Mythical Man-Month," which will be 40 years old next year. https://en.wikipedia.org/wiki/...

Thank God I'm getting ready to retire.

How often do you need to do that? As an "end user" when things work correctly, I'd assert it's infrequently.

But when trying to debug a problem, I agree this is frustrating, and the worst of all is "You are unable to log in at this time. A system error has occurred." and even if you know how to bring up the Console (/Applications/Utilities/Console.app) to look at the error logs, they're not particularly helpful.

So I'll put some words into your mouth and say, "It's important to have documentation available to support troubleshooting or 'power users', but the goal should be that 95% of the time you shouldn't need to RTFM to use the system." Agree?

And access to documentation is separable from existence of documentation. Most of the time, when I'm connected, using a search engine to find this kind of information doesn't bother me. But when disconnected (e.g. sitting on an airplane), not having the information local can be very frustrating.

From a user doc perspective, Apple Mac OS X is a great example of what you can do with a minimum of user documentation, but with very mature and fully enforced user interface guidelines. In fairness, someone new to the platform does need some hand-holding, either training (including over-the-shoulder help from a family member :-) or a good book (I'm partial to the Pogue "Missing Manual" series.)

From a developer doc perspective, if you expect to maintain the software, some amount of documentation, that should capture (1) interfaces; (2) design intent; (3) full build/reconstruction directions (including configuration data, etc) is essential. And "Agile" that ignores these documentation/sustainment issues is just an excuse for write-only coding.

I am pretty sure that that is exactly the wrong thing, then, because the entire point of "business apps" is that people are supposed to be able to build a stable operation on them. If you are changing things so much that you have to rewrite the documentation entirely, that means you are changing them so much that anyone using the software must completely redo their entire process, retrain anyone using the system, and so on.

That's way too much change. If you are changing things enough that you are rewriting documentation every release, then you are not "evolving".

If you have to rewrite all your documentation, you've done something horribly wrong.

Suggestion: Consider focusing on stability for a while, because stability is a huge win for user experience.

So there's this project which anyone can contribute to which doesn't have a thing I want. But unlike many things, this one doesn't require nearly as many specialized skills to produce, so the chances are pretty good I could make it if I cared to spend the time.

WHAT SHOULD I DO!?!?!?? Please help me, Slashdot. I need a way to feel like this is someone else's fault and I can't do anything about it. ... I guess, Slashdot being what it is, I should point out that the above does not actually reflect my feelings on the topic. I actually do contribute documentation updates to projects sometimes.

Would anyone here doubt that a Mac Pro is a 'high end machine,' or that the posted specs for system noise don't make that "quiet?

One difference is obvious, you can go see, listen to, and buy a Mac Pro right now.

Greenpeace is to the ecology roughly what Autism Speaks is to the autistic community, or what Bennett Haselton is to articles that aren't painfully stupid.

This is not news, and it does not deserve attention or reporting.

Well, one option would be to actually make friends with enough people that you could collect your own data.

I mean, it's an Internet comment thread. People are just reporting what they've encountered. It's just that I've consistently found that what they report is wildly different.