When you talk to programmers, sometimes they will talk about methodologies. In fact, some programmers will go on and on and on about them. If you are hiring, they may tell you that they use “agile” practices or “waterfall”. As your eyes glaze over, you may correctly wonder “do I need to care?”
The answer is: No.
The question of methodologies can make a lot of programmers very religious. I’ve seen perfectly normal people get quite aggressive when they started talking about their chosen software development approach. Even the sales people for consulting firms can say quite pompously “We use only agile methodologies in our software development projects” as if they were talking about gold or something. Geez!
If you are not technical and are trying to select a programmer or team for your project, don’t worry about methodologies. Using a particular methodology is no guarantee of success.
Instead, focus on proven results. Ask to speak to their references. Hopefully these are organizations with projects that are similar to yours. IF you are building an online store that will need to service thousands of transactions a minute, then talk to a customer with a similar online store they built. Or if your project is a cool new iPhone app, then find out what kind of iPhone development experience they have.
If you want a successful software project, using programmers with proven track records will increase your chances.
Yeah, but Avonelle, what do all those methodologies mean?
Okay, just because you asked for it, here is some very basic info on software development methodologies:
There are lots and lots of “methodologies”, but they can be organized into two groups:
With a waterfall approach, system development is very orderly. You start by defining requirements, then create a big design (usually a long document or set of documents), then write code, then test/fix the code, then deploy it. Done. Once you move to the next step, you don’t usually go back to a previous step. Sometimes people call this approach BDUF (big design up front).
With an interative approach, software is developed in several “iterations” of usually 2-4 weeks long. Each iteration includes planning, requirements, design, coding, testing, and deployment. With an iterative approach, it is thought that issues and misunderstandings about requirements can be more quickly identified and addressed than a traditional waterfall approach. (Some iterative approaches include agile and scrum.)
Again, I don’t think you need to worry about these things, but since you asked…