Death to Agile?

[Cogman]

http://gwaredd.blogspot.com/2010/02/game-development-in-post-agile-world.html

An interesting article about the short comings (and some of the benefits) of agile programming. I thought it was a good read.

Personally, I get a bit nervous when someone tries to argue that some programming method is "THE" method, and everything else is inferior. However, I've also seen the ugly beast of "This is what I need, you figure out how to do it." Over-structure and under structure is a bad thing IMO, a middle ground is the best approach for programming.

Comments?

 

[Dissipate]

Programming with other people sucks. /thread

 

[IHateMyJob2004]

Knowing various methodologies is what everyone should strive for.

When you go to develop software, you need to be able to use known concepts in order to develop that software.

Now, you might have a small simple straight forward project where everything is known up front. Use waterfall as your basis and tailor it to your needs.

Now, you might have a small project where the customer doesn't know what they want. Use agile as your basis and tailor it to your needs.

I was on a project that screamed agile with longer iterations. Actually, two iterations about 4-6 months each. But we used waterfall even though there were comments against it's use early on. Almost spiral development due to the cycle time. But the customer had half of their wants known fairly early. The second half they didn't know anything about and honestly, I still think they are unsure of some things. Well, I left that doomed project (doomed for reasons beyond this) and department (with the waterfall is all there is mentality). And I am much happier.

The point is, know the major development models. And borrow concepts from each when coming up with a proper approach. No project will be 100 agile and no project will be 100% waterfall.

"Really, we're not tied to any specific development model, we're tied to what is effective" - Mike Beltzer, Mozilla director of Firefox

I have that quote printed and thumb tacked to my cubical wall because it is the ultimate truth.

 

[IHateMyJob2004]

Programming with other people sucks. /thread

Actually, it works out nice. Ever actually try it? It's awesome for deciding things like refactoring or how to best modify a framework on the fly. And it works as a peer review but one that actually works out much better since the co-coders are the co-reviewers. And their understanding of the code is much better. 8 hour peer reviews on code that took a month to write is what sucks.

 

[NGC_604]

http://gwaredd.blogspot.com/2010/02/game-development-in-post-agile-world.html

An interesting article about the short comings (and some of the benefits) of agile programming. I thought it was a good read.

Personally, I get a bit nervous when someone tries to argue that some programming method is "THE" method, and everything else is inferior. However, I've also seen the ugly beast of "This is what I need, you figure out how to do it." Over-structure and under structure is a bad thing IMO, a middle ground is the best approach for programming.

Comments?

I would agree with that. There is no magic formula to guarantee success in software development. Any project can fail, regardless of the methodology, and for a lot of reasons that don't necessarily relate to the particular methodology. Poorly constructed or managed teams will usually end in disaster, regardless of the method being used. You have to value leadership and talent over any specific methodology.

I like the quote from Roy Osherove in his book, The Art of Unit Testing. He starts off by saying, "One of the biggest failed projects I worked on had unit tests.". Using TDD/BDD will not likely save a doomed project. But when used properly and in the right situation, you can get some real good results. The same goes for agile/waterfall. I agree with what IHateMyJob2004 said, you have to use what best fits your team and particular project.

As far as pair programming is concerned, I'm a fan of it. I feel that both developers involved learn from each other and can result in some good quality code. But I think it depends on the people involved obviously. I know some people who just do not work well programming with others.