Go Back
Posted by: Avonelle Lovhaug
Publication Date: 7/16/2008 5:00:00 PM
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…
Category:
By pweber on 17 Jul
Here's another way to explain the difference between waterfall and agile methodologies:
Waterfall tries to avoid change (a.k.a. "scope creep") during a project by attempting to spell out every detail in a specification or design document. If, during the project, the client decides they want to change something, it means a revision of the spec and (usually) a renegotiation of the price.
Agile methodologies were created as a backlash to the inflexibility of waterfall. Rather than try to spell out every detail in advance, agile recognizes that change is nearly inevitable, so it embraces it. The client is involved as a member of the development team. He or she prioritizes the order in which features are delivered. Each iteration delivers a working set of features; the client may decide at any point that the project is sufficiently complete.
I'm not favoring one methodology over the other; both have advantages and disadvantages. I do, however, think it's important for clients to understand the tradeoffs of whichever methodology they select.
By Avonelle on 17 Jul
I think your explanations are good - thanks!
However, I still think for a customer who is not technical and who is trying to pick a vendor, focusing on the methodology options is not helpful. Here's why: with the right programmer/team, both types of methodologies can produce successful results, and with the wrong programmer/team, both types of methodologies will fail.
Instead, to me it makes more sense to concentrate on better predictors of success, like previously successfully completed projects that are comparable. Someone without experience purchasing custom software will have enough to worry about without also trying to wrap their head around the right methodology for their situation. Instead, they should find the right developer or team, and use their recommendation.
Name:
Email (optional):
Your URL (optional):
Comment:
Type the code shown
Top 5 Programmers to Avoid
What everyone should know about bugs
How to tell if an estimate sucks
The Secret to Building a Crappy User Interface
The Problem with Selecting the Lowest Bidder
5 Ways to Control Software Development Costs
Avonelle is an incredibly talented software developer. She works fast, is economical, and offers great insights into the project at hand. She is also not afraid to speak up when she has concerns about a decision or approach. We’ve utilized her talents on many of our software development projects over the years.
Carrie Rocha, Chief Operating Officer @ HousingLink
Sitefinity ASP.NET CMS