In your opinion, what is your single most favoured methodology for developing a web application?
Broad Case: I am contracted to assemble and manage a team to begin the creation of a large web app, what methodology would suit best?
Edit: Methodology being the team/work practice NOT architectural
I think the choice of methodology is less dependent on the technology than on the environment. Web-apps are usually easier to deploy so that might point you to an agile/iterative approach. But that's not the main consideration.
The choice mainly depends on the clients/users. If they're willing to cooperate and spend time to cooperate during the project then you might want to go agile/iterative. If they've got a throw-it-over the wall mentality than you'll need to gather requirements before you can start the project.
Also look at what the developers you're working with are used to. If they're comfortable with agile you're going to have trouble if you'll go waterfall. The other way around is easier but expect a steep learning curve for the developers.
About 10 years ago, I was a big fan of agile processes (Extreme Programming at the time), but I've pulled back from that in recent times - Too often people start out with good intentions in agile land, but wind up not actually following the process, and wind up with a giant unspecified mess of a project.
My advice would be :
For web based projects, it's also probably a good thing to get your infrastructure needs sorted early on. How will you deploy things, where's your test environment etc.
From experience, you should try to implement one of the "agile" methodologies, or some hybrid of them, such as Scrum, XP, or FDD.
The main features associated with these methods are usually:
Developing and releasing new features, or sets of features, in iterations. Iterations can be anywhere between 1 to 4 weeks, depending on the size of the team and the complexity of the features. Typically, the team focuses only one one set of features during an iteration, preferably the set with the highest business value (or ROI).
Using acceptance tests provided by the client (perhaps with help from the developers) as a primary metric for completeness of functionality. Acceptance tests can be codified into executable functional tests, and integrated with a "continuous integration" system, such as Cruise Control.
To the extent possible, encourage the development team to employ a "test-driven design" approach to developing features. TDD tends to promote better, more cohesive code with less coupling between components.
Since you are developing a web application, deployment is a relatively simple act of releasing the code to the right server, rather than packaging it up for sale on a CD or for download as a package. Agile works very well with web-based applications, as you can easily deploy just a few new features at a time.
I would say my favorite (though not perfect) would be an agile methodology. It's not perfect, but much better suited to the constantly changing world of web development.
It's basically based on the idea that requirements constantly change, so only work on things you can deliver in about 2 weeks. Meet up every day with your team for about 15 minutes to discuss today's work. Meet every 2 weeks to plan the next 2 weeks worth of work with key stakeholders (project managers, tech leads and product managers).
Agile does have its critics, and I agree it's not a silver bullet, but it's a hell of a lot better than waterfall. Long development processes with few milestones and little communication almost always end up overdue and over budget. Better to keep things on a short cycle where you can change course often.
Forming a new team to build a large application is difficult. Try to keep things simple and the lines of communication open at all times. Don't be afraid to be brutally honest. I would highly recommend reading up on anything and everything about software development (Try Joel Spolsky's, Jeff Atwood's and my book list)
Good luck!
(note: I removed the "php" tag, which didn't really jibe with "language-agnostic", IMHO)
One recurring theme I notice with respect to the more successful web development is "deploy early, deploy often". The cost of frequent deployments is much lower than with distribution of more traditional executables and install files and the like (although there are arguments for frequent delivery there, too).
When you only have to deploy to your web server, the cost of doing so becomes very small, particularly if you spend a little time identifying opportunities for increased automation in the deployment process as you go along.
Frequent deployment pretty much mandates iterative development, which probably means you should, as mentioned in other responses here, be looking at agile practices. Principles I'd be keen to adopt would include DoTheSimplestThingThatCouldPossiblyWork, more usually abbreviated to the snappier DTSTTCPW, and throw in a fistful of YAGNI to prevent over-design in the early stages.
With those in mind, I'd want to pick a feature and develop enough to get a complete (but simple) working web application into an environment where an audience of real users (at least one, more if you think you need them) can start to provide feedback. Then incorporate the lessons learned from the feedback as you progress.