As a result of software development being a fairly new undertaking, no one methodology has yet been able to claim the throne and be the one methodology to rule them all. In fact, there are many methodologies in use and new ones appearing frequently enough to cause shifts in the ways we develop software. One can at least discern ’categories’ in which these methodologies belong, agile vs. heavyweight , each of which has their distinctive characteristics.
Before presenting an overview of these characteristics, it needs to be stated that this post assumes that a methodology is needed for any kind of large-scale software project. That being said, it seems as if choosing a methodology is as much a stage in the development process as the development of the software itself, but more on that in a while.
The key characteristics
There are many agile methods to choose from, such as scrum  and extreme programming . Boehm  points out some common characteristics among them all. He notes the idea that the lack of documentation is made up for by implicit developer knowledge and that, therefore, agile methods may require a group of more experienced developers. Instead of adhering to a set of processes and tools, agile methods emphasize the individuals working in a project, as well the project itself being amenable to changes during its duration. The last characteristic explains the name, as there is inherent agility in agile methods.
Heavyweight methodologies on the other hand, places emphasis on documentation, standardized processes and capturing the requirements correctly from the get go. This is often done through the use of modeling languages such as UML. Boehm highlights the fact that such projects emphasize efficiency, predictability and a process with a clear goal, in which one matures a software product for its release . Instead of agility, developers get the discipline inherent in such standardizations.
So, which methodology should we opt for?
Supporters at both ends of the spectrum like to point out the flaws of the other methodology. However, Boehm suggests that one should try to balance agility with discipline, especially in sectors with companies needing both ”rapid value” and ”high assurance” . This statement highlights what should be a top priority for developers, namely, what does the customer need?
Heavyweight methodologies are suitable for when companies desire a low risk and when rapid development is not the first priority. This could for instance be applicable to ATM’s, power plant controllers, ERP systems or other, similar, large-scale enterprise software. The constraints are, in most cases, clearer, leading to less ambiguity in the requirements. In the first two examples, the constraints can even outline some of the requirements.
Another factor can be the nature of the development within a certain sector, where a specific system can function for many years and therefore might not need rapid and continuous development, as opposed to say, web development. In web development, new technologies and development trends makes rapid prototyping and development necessary, since the changes are frequent. The factors, both internal and external, in the large scale examples mentioned affecting a given project are conceived to be rarer than in settings that are “plagued” by change.
Agile methods on the other hand can work in those change plagued environments, where high risks are accepted, and where developers can work with cutting-edge technologies for rapid prototyping, such as rails, node.js etc. for the development of commercial apps. Therefore, it might be more suitable for ”startups” and small companies with fast development cycles. Requirements can be vague or even unknown to a lesser extent and then discovered during development. In such environments small teams can be more productive not dealing with bureaucracy and adhering to standardized processes.
An example could be a new technology allowing for a new type of product. At this stage, or in fact at any stage, the priority is not to perfect a product, but rather to rapidly deploy a functioning product and then re-iterate within a continuous development and deployment cycle, enabling a rapid growth of the company in question .
In essence, I have argued that different methodologies have their time and place and that one should select the right tools for the job, the right methodology for the setting. Boehm may well be right in saying that one can even combine the two approaches in some settings. In any case, one needs to analyze the context; what is being developed and for whom? The choices developers make are not made in a vacuum and thus have to be made with the context taken into consideration.
Developers should be comfortable using different approaches to different projects, and this is true not only for methodologies, but also for programming languages and API’s. In that sense, with regard to the comment made in the beginning of this post, the choice of methods and tools for a projects is as much a part of the project as the actual development.
There is a need for pragmatism and objectivity, and it is therefore easier said than done, since many will presumably fall back to what they are comfortable with, even if another method is better suited for the task. Therein lies the danger, in the zealotry of developers, regardless of which methodology one happens to favor.
So how does one know which methods and tools are the right ones? Well, as in any project, some estimations are necessary. If one is to trust thoughts presented here on the matter, one could make a choice based on an analysis of the context of the project, e.g. constraints, requirements, risk of potential changes during the course of the project and so on. This of course introduces further problems of the difficulties of estimating risk for example, however, thoughts on that is best left to a post of its own.
 A. Clark. ”Software Development Methodologies”. Lecture slides, University of Edinburgh. Feb 2014 [Online]. Available: http://www.inf.ed.ac.uk/teaching/courses/sapm/2013-2014/sapm-all.html#/Methodologies_Lecture_Start
 K. Schwaber, J.Sutherland. ”The Scrum Guide”. Scrum.org. Jul 2013 [Online]. Available: https://www.scrum.org/Portals/0/Documents/Scrum%20Guides/2013/Scrum-Guide.pdf
 T. Parr. ”Object-Oriented Software Development”. Lecture notes, University of San Francisco. Jan 2009 [Online]. Available: http://www.cs.usfca.edu/~parrt/course/601/lectures/xp.html
 B. Boehm, ”Get Ready for Agile Methods, with Care”, IEEE Computer, vol. 35, no. 1, pp. 64-69, Jan 2002
 P. Graham. “Startup = Growth”. paulgraham.com. Sep 2012 [Online]. Available: http://paulgraham.com/growth.html