Please Add Evidence

This Wiki is full of your contrary and unsubstantiated assertions. With logical arguments and evidence to back them up, some of them might be innovative or valuable, and worthy of recognition. Without logical arguments and evidence to back them up, they're nothing but questionable opinion.

Let's put a PleaseAddEvidence tag on ideas that might be innovative or valuable if properly supported.

{The money to fund proper studies is not coming; thus, this tag will mostly be seen as nagging. Speculation and anecdotes will have to do unless we all win the lottery. Whoever uses this tag should have to deposit $100 into a pooled research fund, meaning they put their money where their mouth is. -t}

[That's a good idea. The more sources of research funding, the better.]

[Of course, it's also possible to substantiate an assertion with a logical argument. I think this tag is mainly intended to address completely unsubstantiated -- i.e., no logical argument, no evidence, not even anecdotes -- statements of opinion masquerading as fact. For example, if I state that most programmers are careless and therefore StaticTyping should be used to prevent careless mistakes, it would be reasonable for someone to tag my remark with PleaseAddEvidence.]

If one's personal observation is that programmers behave with pattern X under code pattern Y, that's perfectly acceptable evidence on this wiki. You are welcome to give counter observational anecdotes if your observations differ. If YOU really want a formal study of such, YOU pay for it. Nobody is likely to hand you the money. -t

[Utterly unsubstantiated claims -- without even anecdotes, just the bald assertion that "X is true" -- have never been perfectly acceptable evidence on this wiki, as evidenced by the fact that every time you make utterly unsubstantiated claims, you face opposition.]

Let's not do that, then. -t

[Yes. Let's not do that. If you substantiate your claims, we won't oppose them... as much.]

In many cases you are a hypocrite about "evidence".

[Where? When you find it, please tag it with PleaseAddEvidence.]

I'd rather not. This tag is worse than useless, per below.

[It's like WikiPedia's CitationNeeded tag, but permits a broader substantiation than just a citation and it's definitely more polite -- it's a request, not a demand. Rather than being useless, it is useful and it suits WardsWiki's WikiIsNotWikipedia nature.]

That appears to be a contradiction. If WikiIsNotWikipedia, then complaining about citations, or similar, is NOT appropriate. If you have citations, then put it ON WikiPedia and merely link it from here. Formal evidence qualifies the material for WikiPedia, NOT here. -t

[It's not a contradiction. WikiPedia requires cited references of a certain quality, which is expected of an encyclopaedia. Here, it's not necessary to cite published sources, but some evidence is reasonable. Otherwise, shall we discuss -- at length -- the implications of the fact (I use the term loosely) that Mac OS X is faster than Windows?]

I have no problem with one asking for more evidence, but we don't need a damned tag to do it.

[Why not? It's shorter and more consistent than writing out requests longhand.]

How about something more diplomatic such as, "Please elaborate. I would like more details about that statement". It would help improve this wiki's image as an Asperger syndrome cesspool.

PleaseElaborateIWouldLikeMoreDetailsAboutThatStatement seems a slightly more awkard PageName than PleaseAddEvidence, no?

The only thing contributing to this wiki's image as an "Asperger syndrome cesspool" are your bizarre and AdHominem quips like calling (it? us?) an "Asperger syndrome cesspool."

This is a technical forum, not your local pub. Technical fora have an implicit expectation of somewhat stronger rigour than that expected of football babble in the nearest bar, no matter how much you'd like to put ComputerScience and SoftwareEngineering discussion on the same level as conversation about last Sunday's game.

One shouldn't be rude in any topic. For one, it gives one bad habits that may leak into work.

Of course. Is anyone being rude here?

A tag such as PleaseAddEvidence is rude and too vague to be helpful. If you want more detail/evidence/specifics, then ask for it in a professional and courteous way. Formal tags like this make one look like a self-appointed evidence-Nazi.

For example, "That appears to only be a personal observational anecdote. Do you have something more formal or rigorous, like a formal study?".

If they reply, "no", then so be it. WikiZen's are not obligated to fund an OfficialCertifiedDoubleBlindPeerReviewedPublishedStudy for every claim they make. LetItGo.

There's nothing rude about PleaseAddEvidence, except to the person who has none. It's certainly not as rude as calling this/us an "Asperger syndrome cesspool".

I do not accept you as an authority on rudeness judgements. And the Asberger comment was to illustrate an impression certain writing techniques may convey to a reader, not to give a value judgement of content myself. Maybe there is a better way to state the same thing, but I haven't thought of it yet. I'm only mortal. -t

I'm sure you could think of a way to state it that doesn't accuse people of (a) Asperger's syndrome in an obviously negative sense; or (b) being in a "cesspool". That's needlessly disparaging, bordering on insulting, and definitely a discriminatory slur against people who are Asperger's.

TopMind, you've been asking for peer-reviewed statistical studies about the rest of the world's software-development principles for the past eight years. You haven't gotten any, and you're not going to. These studies are not cheap, and there just aren't that many big software projects being done, especially not ones whose developing companies are going to share their secrets.

The plural of anecdote is not data, but anecdotes are what the software world runs on, for better or worse; this wiki has been running on C3 for about ten years, for example. Can you provide anecdotes of your own to match anecdotes like C3 (or similar anecdotal success stories from the WaterfallMethod, FunctionalProgramming, PaulGraham and Lisp, etc.)? Can you -- or anyone -- RaceTheDamnedCar of table-/SQL-orientation?

Much of this criticism is too general for me to respond to in a specific way. I generally only insist on formal studies if one insists a given claim is "strong". I'll take up specific topics AT specific topics. As far as PaulGraham and Lisp, Yahoo eventually rewrote much of the app in AlgolFamily languages. Thus, we have a clear counter-anecdote for that one. (For cutting edge and start-ups, a HackerLanguage may be TheRightToolForTheJob. Long-term staffing is a secondary issue compared to gaining market share fast and early.) As far as evidence for tables/relational, I don't claim them objectively better than alternatives. That they often work well is mere experience of mine. (Although, there are known data factoring problems with hierarchical-only databases. I don't have any current references at this time. LimitsOfHierarchies may suggest some.)

{"As far as PaulGraham and Lisp, Yahoo eventually rewrote much of the app in AlgolFamily languages." And ever since, Yahoo has gone from success to success, until it has become the world's leading e-commerce, search, and Internet infrastructure company. Not.}

Yahoo has fouled up or squandered multiple NON-lisp projects also. For example, if they had made Geocities easier to author, it could have been the first Facebook-like and/or Blogger-like tool. They appear to have a problem with strategy, not coding speed. And from personal experience, they also have had poor customer service. They are arguably the Xerox of the Internet age: had the right beginning ingredients, but didn't know how to bring them to market. -t
{It's evidence that their decision-making was bad in general. Maybe, had they stuck with Lisp, Yahoo Stores would still be a thing.}
Whatever the reasons, Paul Graham got rich out of it, and managed to write a product 10-15 years ahead of its time -- he and his company were basically doing AJAX programming in 1998. Of course, nowadays, anyone can do AJAX programming in ordinary, ALGOL-flavored JavaScript... Yahoo should have waited for JS, perhaps, instead of trying to rewrite Yahoo Stores in PHP.
- {Real AJAX wasn't even possible until 1999/2000, because it's dependent on the XHR API.}
- It looked like plain-jane HTML to me the time.
Store sites have more or less become a commodity since. There are multiple open-source Php e-commerce systems, for example. It's difficult to manage both cutting edge projects and compete on in a commodity market. Asking a large company to have both mindsets may be asking too much. I've rarely seen it done well. Google and Microsoft obtained near monopolies rather than compete on commodities. -t
EditHint: move above to WebStoresDiscussion

First poster: it sounds like people here should just avoid the word "strong" in making claims. As Top noted (and I agree with) over on FakeIndustryCanon, this is a soft science; "works for me" or "works under these circumstances with this team" is easy to prove, while an unqualified "works" is probably impossible. I'm reminded of a theory of government I once heard: that outside of pathological cases (and I think we can all think of at least one), what matters isn't how the government is constituted, it's the quality of the people in it. I'd say that the same thing is probably true about software: with intelligent, hard-working developers with an eye to self-improvement and improvement of the codebase, you can use any methodology from Agile to Waterfall and any language from PDP-7 assembly to Rust or Ruby, and get good results.

And I absolutely respect Top saying that tables are what work best for him. I've never cared for them very much myself (especially not SQL), but I've also always preferred history and logic over higher math, and I enjoy working with CeePlusPlus; so if I'm going to argue with Top, I'm also going to argue with the FunctionalProgramming people and the whole consensus of the wiki. (I'd also end up in a fight with the ExtremeProgramming people. Sometimes, occasionally, requirements really can't be known in advance, but if your organization needs to write a payroll system and it can't draw up a full list of requirements before you first set keyboard to IDE, something has gone very seriously wrong.)

Also, whoops -- it was Top who said that the money wasn't forthcoming in the first place... I should read more carefully!

CategoryTag

DecemberFourteen