There are now a a variety of programming methodologies: Scrum, Extreme Programming, Kanban to just name a few. Most of them combine several more basic techniques (for example frequent iterations). However, nearly all of them state that their combination of technics is the only way to write good software.

I don't think that there is one way that's best for each and every project. Instead I'm interested in independent scientific evaluations.

  • What basic techniques work best for which kind of project?
  • Is there any advantage in the combination of certain techniques?

As I don't have time to go through primary literature I'm especially looking for a book. I know that there is Peopleware, but it is a bit old. There are already several related questions (Are there any scientifically rigorous studies of coding style principles?, Scientific evidence that supports using long variable names instead of abbreviations?...)


2 Answers 2


As much of a fan of empirical data with rigorous statistical validity, I don't think you can scientifically prove that one methodology is any better or worse than any other.

There are many factors that go into chosing a methodology. In Rapid Development: Taming Wild Software Schedules, Steve McConnell identifies a number of factors: level of understanding of the requirements, level of understanding of the architecture, desired reliability, risk management, schedule constraints, amount of process overhead, mid-project "course corrections", ability to provide the customer with visibility, ability to provide management with visibility, and sophistication of the development team and management. There are others, as well, such as organizational culture, so there probably isn't an exhaustive list anywhere.

Even given the exact same project, there is also the team factor. If you take a team that has consistantly delivered software using the plan-driven spiral methodology and throw them into Scrum, they are going to experience a decrease in productivity, an increase in thrashing, and have to overcome a new process model before they can come around to being successful. Even though another methodology might be more suited, there's always the business need to actually deliver the software. That's why process improvement efforts are frequently long-term efforts and not overnight - major changes are shocking to a team and (even if the methodology might be better suited on paper) can cause a decrease in productivity.

I'd recommend picking up Rapid Development, along with Software Project Survival Guide (also by McConnell).

  • 1
    There are an (almost) infinite number of degrees of freedom, making science relatively difficult to apply. Maybe economics would be a better starting point.
    – S.Lott
    Jan 24, 2012 at 14:58
  • @S.Lott That's a good point. The most influencial work that I'm familiar with in software engineering economics is Barry Boehm's Software Engineering Economics. However, it focuses on making program-level and project-level engineering decisions based on risk, cost, and value rather than on chosing a lifecycle methodology.
    – Thomas Owens
    Jan 24, 2012 at 15:11
  • Of course it is not easy to do science in this field but for example coding wars seem to produce fairly reliable results.
    – ACNB
    Jan 24, 2012 at 15:31
  • @ANCB It's relatively easy to perform studies in software engineering, in some areas. There's an entire area of study devoted to empirical software engineering. However, once you enter the realm of project management, you have to contend with people, and it becomes much harder to develop rules and absolute facts.
    – Thomas Owens
    Jan 24, 2012 at 15:32
  • Excellent answer Thomas, I think some of the points here would add to your answer to Are there any studies on the Efficiency/Effectiveness of Agile vs Waterfall?, especially since this question has now been closed.
    – Mark Booth
    Jan 24, 2012 at 17:16

The most important factor by far in a software project success is not the methodology. It is the team.

  • +1. And I would add that a good team can be slowed down when choosing the wrong methodology.
    – Giorgio
    Nov 12, 2012 at 7:03

Not the answer you're looking for? Browse other questions tagged or ask your own question.