“Keeping you up to date with everything software engineering!”

What are Agile Methodologies

Software Process | November 07, 2004 | 6 comments

The other day I was looking for an article that would give me a quick description of what are Agile Methodologies including short overviews comparing and contrasting the main differences between the different agile methodologies. I came across a great article/essay titled “The New Methodology” written by Martin Fowler.

In his article he gives a brief history of Agile methodologies, what is the reason behind agile methods as well as an overview of the different agile methodologies. If you want to learn more about agile methodologies or don’t have the patience to explain to a co-worker or friend what agile means I recommend you send them a link to this article.

Related Links:

• Article: “The New Methodology
• Martin Fowler

Help Support Us By Visiting Our Sponsor

10% of our revenue from these ads go towards scholarships!

Comments

November 7, 2004 06:35 PM | Louis-Philippe Huberdeau commented:

Sorry about the promo, but it’s related.

In our last conference we had a session on Agile Development by Alex Pukinskis. The session, along with all other sessions, have been recorded and are now distributed on a CD-ROM.

http://conf.phpquebec.org/en/cdrom2004/session#agile

I used agile development myself for a small project and I consider it was a success. It’s very interesting for the developpers and the clients.

November 7, 2004 11:23 PM | Ness commented:

When reading the beginning of this paper I found myself nodding along agreeing with a lot of what was said. But then I got to this point:

“Agile methods are adaptive rather than predictive.”

And I thought to myself. I guess I’ll never use this method in my professional career.

Some Thoughts: We are trying to be software engineers, are we not? We need to design and plan our systems, not let them grow on their own over time.

Engineers document their products to death for a reason. Do you know what that reason is?

Source code will never be a design document. It is the how, not the why.

The why is worth much more than the how.

Iteration can and should be part of the “engineering methodology”.

How can this method be a valid development model for an engineering product?

This post has motivated me to review a paper I think is influential and in-line with my above comments. Look for it some time next week.

November 12, 2004 03:32 PM | John Kopanas commented:

I see where you are coming from Ness. I just think different problems with different characteristics need different methods to get to the solution. A nuclear reactor with requirements that don’t change need a very different method than a business application that might need to evolve a lot even before the first version is finished.

I guess we can debate though if business applications need an engineering methodology or just a methodology.

What makes a methodology an engineering methodology to begin with?

November 26, 2004 03:40 PM | Niraj commented:

Hey guys,

I know this is a late comment since the article has been up for a while, but I just wanted to point out that as an engineer, it is “our” job to ensure that we bring together “best practices” used in industry to ensure that the best possible outcome will be produced given the operational constraints (i.e. cost, time, resources) identified at the onset of the project. The more knowledge of best practices you have the more process permutations you have at your disposal. As we all know, there’s no perfect process that can be applied for all projects. What’s my point? Keep reading up on methodologies and what not. You’ll find that they are often permutations of a number of existing processes…similar to the academic world, whereby 1 researcher modifies a constraint for a given principle and calls the new principle his own.

January 21, 2005 10:48 PM | J. B. Rainsberger commented:

This is part of the essential debate about software development. Is it engineering or craft? I think we’re a long, long way off from SD being engineering, but that’s just my bias and my opinion. I don’t understand engineering enough to know the distinction clearly. Still, let me ask a question:

Suppose, for a moment, that when we go to build a house, we /could/ make fundamental changes to the house relatively inexpensively after we’ve started building it? Suppose we could extend the foundation an additional 200 sq ft after we’ve built the entire frame and most of the ground floor. If we could do that inexpensively, and if our customer wanted us to do it, wouldn’t we do it? Would we really say, “No, I’m sorry; that’s not in our plan, so we’re not going to do it”?

I understand why we don’t do it now — it would require restarting the project — but in software we don’t have that problem. We /can/ improve the design of existing code relatively inexpensively (at least, compared to building a house, or a bridge) and with relatively little risk (ignoring safety-critical systems, for a moment). That makes an adaptive approach much more reasonable for software than it would ever be for the other engineering disciplines. In this sense, software development doesn’t /need/ to be engineering, because it can be more flexible than engineering needs to be.

Isn’t that a /good/ thing?

January 22, 2005 12:34 PM | mhp commented:

JB, if most software today was designed for change, then it would be easy to make the changes you describe, because the change would be localized. The problem with most of the software out there today, is that if you need to change something, you need to make changed in many places. Some changes are forgotten/missed or the changes have adverse effects because other parts of the code are too dependent on the implementation. The changes should be hidden from everything but the module that is changed. The current methodologies that focus on implementation cannot handle these issues because the information is not hidden from other parts of the system. Resulting in unmaintainable software! The agile methods (as I’ve understood them) may get the the first version of a product out the door quicker. But, if you cannot easily maintain it then version 2 is late… and likely rewritten. (How many times have you phase “completely rewritten” in changelogs… that scares me) It means it was not designed well enough for change the first time. It that a /good/ thing?

Using your house analogy. If you needed to build an extention, instead of having to modify many parts of the house, design the house so you just change the portion of the wall where the extension is going. Some of the design for change ideas that would go into the design of the wall would be:

• don’t run pipes/wire/ductwork where an extension could go
• don’t put a support post in the middle of a wall where an extension could go.

These ideas should go into every piece of software, not just mission-safety-cost critical systems. The sad thing is that this is not a new idea. But as with many in the industry, the low barrier to entry (i.e. cost of starting to produce code) you described above, results in not having the proper training to build. I could read a book on building a house, but does that make me a house builder?

Post Your Comments

Comments:

Name:

Email Address:
(note: not displayed)

URL:
(note: displayed with comment)