Talk:List of software development philosophies

From Wikipedia, the free encyclopedia
Jump to: navigation, search
WikiProject Computing / Software (Rated List-class, Mid-importance)
WikiProject icon This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
 List  This article has been rated as List-Class on the project's quality scale.
 Mid  This article has been rated as Mid-importance on the project's importance scale.
Taskforce icon
This article is supported by WikiProject Software (marked as High-importance).

This is not a philosophical category[edit]

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[edit]

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[edit]

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 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 (talk) 16:11, 24 February 2012 (UTC)

Obvious superfluous set of techniques[edit]

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. (talk) 19:05, 31 August 2011 (UTC)

Missing philosophies[edit]

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! (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?[edit]

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 don't know the name of this particular discipline[edit]

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 (talk) 16:56, 2 October 2013 (UTC)

Duplicates and compositions[edit]

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)