What is/are the best software development philosophy/ies?

Like stated, there is now answer without an context. In my computer science MDA courses I now use Mendix. It will alllow you to model the domain but also to connect with legacy data and it supports Scrum As an alternative I used Cathedron, but that is much less fancy.

There are no global answers to this kind of question, only local, contextual ones. This is true under either sense of "global": whether you mean a single overarching philosophy (be it agile, software engineering, craftsmanship, software as fine arts), or whether you mean individual "best practices" that apply to every possible situation where people develop software - embedded, Web, games, commercial, in-house, scientific, etc. There are some regularities that run deeper than others. Event-driven versus pub-sub is a surface distinction; correctness is a deep concern against which the two major prongs of attack, testing and proof, have generated a number of strategies, some of them quite robust (automated testing, type systems). The best you can do is to ensure your enthusiasm for a particular answer or flavor of answer is no greater than the generality of the answer deserves.

I would say that in the context of the current anarchy of production (it seems the larger the company the less compatible they are with planning and with being able to wait for a return on profits; and as a corollary, the more delirious and badly informed their "experts" and stakeholders are) an agile approach like SCRUM is absolutely necessary otherwise you won't Get It Done. Agile and SCRUM are born out of "Just in Time" crisis contexts (ten years of recession in Japan), and they are really great for the crisis: let's go with Mike Cohn: http://www.mountaingoatsoftware.com/ In a context in which in depth planning is possible (which context that is, is subject of another thread) a more engineering rich approach would be great. In those more level-headed contexts, let's go with the Agile Unified Process: http://www.ambysoft.com/unifiedprocess/agileUP.html Thumbs up to Scott W. Ambler who is reasonable.

My opinion is the following: software development mathematically speaking represents the problem of exponential complexity. Specifically exponentially complex is the debugging stage. For now program's debugging represents verification of all paths of execution path by path. And as program's size grows linearly - number of paths grows exponentially. Here the exponential complexity comes from. It is well known to all practitioners that 2 changes or amendments of apparently the same complexity done at the early stage and at the advanced stage of software system development require very different effort.   All existing development methodologies search for solution at the design and/or administrative stages / areas. They try to administratively restrict iteration's duration or meeting duration - nice to wish. Specifically SCRUM is purely administrative schema. I see the gist of Agile method as follows:"We don't manage do existing work properly - so let's get due for additional obligations". Saying “additional obligations” I mean obligation to obtain all changes in requirements which might rise within development process. When speaking about philosophy - it cannot be explained in terms such as "2 or 4 weeks" (see SCRUM description in Wikipedia). All existing methods are explained using improper and /or undefined terms and implicitly make unrealistic assumptions. Any mathematician could reveal problems of this sort in these explanations which cannot be called "proof" My Gnotum methodology is based on 2 existing ideas: Iterative development introduced by James Martin in 1991 and Object-Oriented principle introduced by Bjarne Stroutsrup in 1981 (not sure). Agile methodology introduces itself to be a sort of Iterative development, but if you read Wikipedia's article deduced to Iterative development, you'd see that Iterative development supposes periodical redesign and recoding. Agile doesn't speak about it. Practically it isn’t worth to redesign and/or recode in order to find proper place where the currently visible change(s) could be easily intruded into the existing system. Gnotum methodology gives strict criteria for when redesign and/or recoding are necessary. The gist of the Gnotum methodology is the following: 1.       Software development process is entirely analogous to the process of creation of a new model of, for example, aircraft. System architect must play the same role in the software project as the Chief Constructor of aircraft. In practice as the code starts to be written – design documents and System Architect become irrelevant. The knowledge is distributed in the heads of team members, and neither Team Leader, nor System architect manage to keep control over the situation. As a programmer leaves – part of the knowledge is lost. The trick with pair programming is expensive and doesn’t help much. Obviously human’s psychology is not taken in account. 2.       In order to keep control over the process, programmers must be obliged to implement the designed model exactly as is. Object-Oriented style is mandatory as it allows for visual verification whether the code really implements the model (design). If it is impossible to implement the design as is (which is very likely at first iteration) – programmer should report to the System Architect and be ready to change the written code in order to implement improved model. This requirement directly correlates with situation when productive engineer reveals that new model of aircraft cannot be implemented exactly according to the provided drafts. Could someone imagine that productive engineer fixes error in the draft approved by Chief Constructor and doesn’t report about the change done? 3.       The Gnotum Methodology is revolutionary one because it states that cancelling of “Principle of minimal changes” or “Don’t touch working code” represents the key decision allowing for solving all other problems. 4.       Gnotum Methodology introduces idea that the only self-explanatory code is the code written according to the Object-Oriented principle AND using only the terms appearing in the current version of the model (design). All traces of previous versions should be removed from the code. Such code is really given for reading as a sort of document – similarly to reading of geographical maps and drafts. 5.       Gnotum Methodology includes middleware library code which represents the minimal necessary simplification means allowing to use Object-Oriented principle in the areas where API provided with SDK doesn’t allow for Object-Oriented coding, namely: multithreading and text parsing. I applied to PCT authority. The patent application documents contain 50 pages of text and 35 pages of drafts. The patent documents are already published. Anyone interested could search in the WIPO database. The publication number is: WO 2011/013116 I’ve got a written opinion from US Search authority which reads that all this is obvious – and for this reason is not patentable. Tell me please, somebody thinks that cancelling of the “Principle of minimal changes” is the obvious thing. I’m going to apply for patent to USPTO shortly

I would say from personal experience - Control Tables.Control tables can be completely portable if required and encapsulate the logic neatly in a small space that can be quickly visually scanned (even, in theory, non -programmers) without needing to know a particular computer language or syntax. The technique is interpretive but the tables can be designed in an optimal way to speed interpretation/execution by most paradigms/languages.