Talk:You aren't gonna need it

Aren't or Ain't, along with 'going to' or gonna

The existing title is inconsistent. Either be consistently formal or consistently informal.

• Coherent and right acronym: "You ain't gonna need it." (YAGNI)
• Coherent but wrong acronym: "You aren't going to need it." (YAGTNI)
• Incoherent: "You ain't going to need it." No one would ever say that! Artificial. ain't is informal, but going to is formal.
• Incoherent: "You aren't gonna need it." No one would ever say that! Artificial. aren't is formal, but gonna is informal.

If you have "gonna", you have to have "ain't", as well.

"you aren't gonna need it" 11200 hits at Google

"you ain't gonna need it" 17900 hits

The title needs to be changed, and I certainly advocate for consistent informality: "You ain't gonna need it." Pet peeve: artificially stiff and formal and pretentious language in encyclopedia articles, which serves to distort and misrepresent instead of clarify. -msh

You aren't gonna need it is how it was originally formulated. The title should not be changed, we can't just change slogans to fit our grammatical preferences. http://c2.com/cgi/wiki?YouArentGonnaNeedIt Martijn Meijering (talk) 19:23, 2 August 2016 (UTC)

Aren't or Ain't

Isn't it "You AREN'T Gonna Need It"?

I once heard that people prefer ain't to aren't, though I don't know why. -- Taku 01:22, Apr 12, 2005 (UTC)

It would be "You aren't GOING to need it." if you want proper English, but that just doesn't have the same impact.

Isn't the c2 wiki a definitive source on these terms? It uses the proper english, and I would disagree that the proper english has less impact. Cedear 17:49, 27 February 2007 (UTC)

I think the lead should have both alternatives. I added "You aren't gonna need it" and referenced with c2 wiki. Fridek (talk) 14:05, 6 December 2011 (UTC)

Appropriateness Of Acronym Components

Jon (talk) 17:06, 19 November 2008 (UTC): I have a hard time accepting the formalization of YAGNI as an industry "philosophy term", not because the philosophy is wrong but because the acronym's components do not reflect the philosophy. The philosophy is "do not add features until you need them", but the acronym says that you already don't need them, which is terribly presumptuous and as such it is prone to abuse by hard-nosed, clueless tech leads and managers who end up demanding a crippled product because features didn't get implemented to begin with. The acronym should instead be something along the lines of "AYGNI", or "Are You [Truly] Gonna Need it?" More here

Wikipedia talk pages are for improving the article, not for pontificating on the subject of the article. -- 68.111.35.169 (talk) 02:39, 18 September 2014 (UTC)

Good Aspects

Isn't there at least a good aspect in this philosophy? —Preceding unsigned comment added by Theups (talk • contribs)

No, there is none whatsoever. —Preceding unsigned comment added by 209.17.128.161 (talk)

Of course there are, c2:DavesRealExampleWhereThinkingAheadWouldHaveHelped and c2:YagniExceptions. -- intgr 16:04, 18 April 2007 (UTC)

I don't believe either of these pages are good counterexamples to YAGNI. As evident by its title, the first page is about a project that did no planning. This is not YAGNI; on the contrary, YAGNI requires planning beforehand so you know what YGN and what YAGN.

Similarly, the other page describes dysfunctional projects that blame YAGNI with no evidence YAGNI was the problem or even used; or implausible hypotheticals like that of a DBA who refuses to implement required functionality but is happy to implement unplanned whims. Clearly, in a case like this, what YAGN is the DBA. Corvus 01:53, 22 July 2007 (UTC)

Occam's Razor

This should be related to Occam's Razor. Metaxal 22:50, 21 July 2007 (UTC)

No, it shouldn't; any similarity is at best superficial, an in any case creating such a relationship would be OR. -- 68.111.35.169 (talk) 02:46, 18 September 2014 (UTC)

Ouch

"A logical conflicting factor is the notion of completeness, which tends to define missing options, or facets, mostly likely to be needed: for example, among features which allow adding items, deleting items, or modifying items, completeness could be used to also recommend "renaming items". The critical impact of completeness can be seen in some types of wiki-collaboration software which can add or delete image-files, but not simply rename images, at all, even after several years of software upgrades."

I wonder what wiki engine they are referring to? :-) Tbsdy lives (formerly Ta bu shi da yu) ^talk 13:17, 6 October 2008 (UTC)

Simple Decision

This should be a very simple decision. YAGNI is a term programmers use, and it has an agreed meaning. Whether you LIKE that meaning is not relevant. This is part of the vocabulary of modern programming and as such should be included in Wikipedia. —Preceding unsigned comment added by 12.116.90.198 (talk) 18:57, 30 March 2009 (UTC)

Totally aggred ! — Preceding unsigned comment added by 2A01:E34:EC06:8410:9C6A:A181:5067:BF72 (talk) 15:08, 16 October 2015 (UTC)

The Balancing Concerns section does not belong

The point of the article is to define what the term means.

The Balancing Concerns section is editorial in nature, and presents one person's view about whether YAGNI is appropriate. I don't think it belongs in the article.

Eric.Gunnerson (talk) 19:34, 3 June 2009 (UTC)

I agree. It also cites no sources, so I'm adding the "original research" banner. The article should probably just be cut down to the intro paragraph (which has sources) and rewritten based (at least initially) on c2 wiki stuff and Kent Beck's "XP Explained." DuelinMarkers (talk) 18:55, 9 August 2009 (UTC)

Agreeing with Eric. It would be perfectly OK to present criticism of YAGNI in a separate section, but it shouldn't be presented as if it were part of the philosophy. Martijn Meijering (talk) 20:10, 30 April 2010 (UTC)

The article has been in a "POV-challenged state" for a long time, with no prospects of improvement any time soon. I suggest we remove the balancing concerns section altogether, making sure the remainder of the article is properly neutral and descibes YAGNI as a widespread opinion in agile software development circles, not as a generally accepted fact. I say this as a strong supporter of YAGNI. Martijn Meijering (talk) 20:53, 11 February 2011 (UTC)

I've removed it, as WP:OR. If anybody wants to advocate these points (at least some of which are not without merits, BTW - but still original research) - to comply with WP:NOR it is necessary to write an article on it outside Wikipedia and then put a link to it to the talk page (and if in doubt - feel free to ask me where the article can be published - I know a place where a good article on this subject will be welcome). Ipsign (talk) 06:34, 4 February 2012 (UTC)

Neutrality

As of 2016/04/17, I removed the neutrality banner as per the discussion below. (DanBrotsky (talk) 15:28, 17 April 2016 (UTC))

Prior discussion 1: As of 2016/3/25, there is no Rationale section as mentioned in the Prior Discussion 2 comment below. There is only a Context section. I believe Context is an appropriate heading for the material in that section, and it feels completely neutral to me. Given that there's been no other discussion of neutrality since it was introduced in 6 October of last year, and that the reason for posting the neutrality banner has been redacted, I think it's time for the neutrality banner on this page to go away, as per the removal conditions. DanBrotsky (talk) 00:11, 26 March 2016 (UTC)

Prior discussion 2: Given the removal of the Balancing Concerns section (however bad it was), this article now contains only arguments in support of the YAGNI principle within the Rationale section. Without hunting for sources at the present time, a few sample arguments against YAGNI might include:

• Especially for large systems, it can be easy to forget the precise implementation-details of a family of related functions. Although existing code can be revisited later, it is difficult to document every reason for each and every implementation-decision, factors which may come into play when expanding the code to create a feature or change a behavior which was anticipated earlier.

• Again esp. for large systems, it can be difficult to keep track of notes about how an algorithm might be implemented without either cluttering existing code with comments about components which do not exist yet, or risking that such information might be overlooked if taking the approach of storing pseudocode separately, as there may be various possibilities of what a left-for-later function might be called e.g. forge_signature(string nameOfPerson), forge(Signature signature), do_forgery(Document, string) etc. Coding standards would assist programmers in guessing what to search for, but they might give up after a few guesses and use an approach other than what was specified earlier — something inelegant, confusing, high-complexity, or plain-old-incorrect — if not all of the above. Koyae (talk) 23:13, 6 October 2015 (UTC)

Original Research in Context?

I'm a little concerned about this sentence in the Context section: Used without continuous refactoring, it could lead to disorganized code and massive rework. It is presented without reference, and thus appears to be original research. This sticks out in what otherwise is a well-referenced article. I suspect that this sentence comes from one of the references, but I am not familiar enough with them to cite it properly. Perhaps someone more familiar with XP literature could add the reference? DanBrotsky (talk) 00:20, 26 March 2016 (UTC)

2023 comment: Spaghetti code has more 2 more meanings over the original "a piece of code full of GOTO operators, that's hard to read" idea. OkiPrinterUser (talk) 14:59, 6 June 2023 (UTC)

Ron Jeffries has written...

About:

     XP co-founder Ron Jeffries has written: "Always implement things when you actually need them,
     never when you just foresee that you need them."[5]

At first glance, the wording seems a bit muddled. You can see that you need something, and you can foresee that you *will* need something. But how do you foresee (which implies the future) that you need something (now)? Or maybe that was deliberate, to highlight the very absurdity which that wording itself suggests. Toddcs (talk) 21:30, 5 April 2016 (UTC)

He means "when you foresee that you will need them", but left out the "will". Martijn Meijering (talk) 19:38, 28 September 2016 (UTC)

Seems like an obvious error in Jeffries' sentence. I've added [will] to the quote. Modest Genius ^talk 12:00, 30 January 2023 (UTC)

Good edit. Andre🚐 18:50, 5 February 2023 (UTC)

Missing context

The article mentions the hurdles of supporting a large app (let alone "software package"). However, it doesn't address the other reason to dismiss features as YAGNI - the availability of other products, especially ones already designed for those "extra" features one wants to implement. Simply put, there's no mention of the UX, User eXperience part - overburdening, alienating the product in question's end users with various new buttons OkiPrinterUser (talk) 14:56, 6 June 2023 (UTC)