Talk:List of software development philosophies

This is not a philosophical category

This category conflates philosophy and the philosophy of technology with methodology. It should be renamed to "software development methodologies". Philosophy "is the study of general and fundamental problems, such as those connected with reality, existence, knowledge, values, reason, mind, identity, and language." It is determined by what is most basic in our abstract, universal, and theoretical concepts. It is not based on the highly developed practices of the applied sciences in the colloquial sense of a philosophy, although it may reflect on these topics in the process of systematic reflection. If no action is taken on this issue in the near future I will return to make the appropriate edits. --Aliensyntax (talk) 01:24, 7 May 2015 (UTC)

This article's existence

I'm not sure this article needs to exist- between the two categories I added to the See also, this list seems pretty superfluous. --maru (talk) Contribs 01:24, 3 January 2006 (UTC)

It doesn't offer much more than a category would right now. But it could be a lot more useful if it added a basic one-sentence description of the item (it being difficult to ascertain anything about them right now without visiting each page), or if it were structured according to the type of approach. --David Edgar (talk) 14:23, 31 March 2010 (UTC)

Blind Men And Elephant Approach

There are very few pages for BMAEA that link to anywhere other than reposts of this list, or to acronym explainers. I searched for a while and found http://www.pdl.cmu.edu/PDL-FTP/associated/issre09_pan.pdf as a source for a possible link to programming. This isn't a design philosophy, it's a data analysis method. I've pulled the entry out of the list. If anyone wants to prove to me that this BMAEA is a real thing, go ahead. — Preceding unsigned comment added by 195.224.9.194 (talk) 16:11, 24 February 2012 (UTC)

Obvious superfluous set of techniques

I wonder if something could be said of the fact that there are basically too many software development techniques and philosophies to be worth understanding. None of these techniques are associated with real published empirical evidence of their claims, and so it is impossible or very difficult to really judge the kind of situations these techniques are really suitable for.83.208.165.249 (talk) 19:05, 31 August 2011 (UTC)

Missing philosophies

This article is still missing a number of prominent development methodologies. Some of the omissions include:

• Broken trombone
• Moving target approach
• Never Use Keyboard Entry (NUKE)
• Steal And Use Code You Didn't Develop (SAUCYDD)
• Walrus of paranoia

I wasn't able to find articles for any of these techniques, so clearly there is much work to be done! 142.20.133.199 (talk) 19:49, 17 June 2013 (UTC)

^I've googled all of these and the only hit is this talk page, have you made them up? QueBurro (talk) 08:58, 11 August 2014 (UTC)

Should it amuse that data-driven development is not in this list?

Should it amuse that data-driven development is not in this list?

If amused, see talk that that article.

G. Robert Shiplett 22:00, 23 July 2013 (UTC)

^ it's under "Software development processes" QueBurro (talk) 09:00, 11 August 2014 (UTC)

^^I also think data-oriented design should be on this list. Pulu (talk) 19:46, 24 August 2020 (UTC)

I don't know the name of this particular discipline

There is a programming philosophy which stresses that, for procedural languages, programmers should focus mainly on the basic and common features of the language, and eschew bizarre language constructs unless they are necessary. The idea behind this is that portage from one procedural language to another would be blissfully easy, since we try to use the features that are common among those languages. I don't know what the name of this philosophy is, though -- I forget it because I'm stupid and my brain hurts. Does anybody know the name of that particular programming philosophy? It might be on the list already and I just don't know which one it is. I perused through a number of them that sounded similar, but I didn't see those ideas expressed anywhere. I think, whatever the name is, it would make a good inclusion to the list. — Preceding unsigned comment added by 71.47.249.42 (talk) 16:56, 2 October 2013 (UTC)

Duplicates and compositions

Solid and Dry are in the list twice.

Solid is an acronym composed of other acronyms. Everyone ok if I change the ordering so that Solid unfolds to its parts? QueBurro (talk) 09:04, 11 August 2014 (UTC)