Many different software development methodologies have been created over the years. Most of them work fairly well. But they all really kind of derive from the Scientific Method.
The scientific method is roughly as follows:
1) Ask a question.
2) Gather information about the question.
3) Create a hypothesis that explains the observations.
4) Test the hypothesis through experimentation and then refine and retest it.
5) Publish the results.
6) Continue to test the results and refine the hypothesis incorporating external input.
In software we have a method that is often referred to as code and fix.
If you look at the scientific method it would be more or less.
1) Ask a question.
2) Create a hypothesis.
5) Publish the results.
6) Refine the hypothesis incorporating external input.
Which kind of works but is frankly an insult to anyone using the software. In a lot of ways it is a lot like religious dogma. Except that in religion refinement based on external input is almost never done or if it is the step of gathering information and testing the hypothesis are steps that tend to be skipped.
Getting back to the scientific method as applied to software.
All reasonable processes have ideas like stating the problem, gathering requirements, creating a specification, testing, documentation, and finally publication followed by iterative refinement.
Most software usability and other issues are caused by not spending enough time observing and testing. And often publication is done in a hurry, which also occurs in the scientific community as well, but less often due to the stigma of publishing something that is subsequently shown to be incorrect.
In software the rigor that is often associated with the scientific method tends to be fairly rare. There is a pressure to perform. Not many years ago there was the idea of "Internet Time" which led to a plethora of buggy software. Getting your software to market before anyone else has been something that many companies embraced as the best way to succeed.
However, over time we have observed that fast an speedy doesn't always win. The tortoise and hare children's story is a classic example of how this lesson was learned, repeated, and well know. However, there still remains a segment of society that embraces the idea that being fast at the start is the way to win.
Long term we find that software companies that embrace quality and continuous rigorous improvement of quality win in the long term. This is a common theme in successful businesses as well.
In the end we don't need some new software development process. Every one of the good software development methods are really just an application of the scientific method with a lot special words attached that tend to disguise the underlying methodology in an effort to make it seem new and different.
