I’m not a fan of Rush…ing development.

Jokes aside Rush is some good stuff when you’re in the mood. But today I want to go into a fundamental problem with agile the be all end all of software development.

Who am I kidding, I can’t actively criticise agile on the internet. That’s heresy! Okay, article over. Bye.

No, everything devised by humans has flaws no exceptions and while agile is a fantastic methodology today I’ll be picking apart less the methodology but rather the way I’ve seen it applied in the industry.

Responding to change over following a plan.

This is one of the most counterintuitive statements of the agile manifesto, and rightly so. As humans we like to compartmentalize, organize, and quanitfy anything we can get our dirty little hands on. But plans can only get you so far, and you can’t quantify everything which is why this part of the manifesto is really something special. You must be able to be flexible, because problems are flexible and if your plan to solve it can’t change you’ll end up speaking into a wall.

But here’s the problem with the manifesto that I believe encompasses the entire manifesto but hits here really bad. It’s too vague. Let me explain.

The four principals are simply put, too vague and leave too much open to interpretation. Now the Agile Alliance attempts to expound upon these four principals by going into detail on what the four principals mean but this initial vagueness has bred a micro culture of developers and project managers who see this line:

Welcome changing requirements, even in late development.

And go nuts. This statement has been the source of a lot of frustration in the programming industry. Especially in those projects that follow the agile methodology.

The point that this statement is trying to make is that when you are building software, you should try to keep things reusable or at least try to abstract most of the functionality of your application. And to a point it does mean that any good developing team should be able to handle changes even in the later stages of development. This does not mean you redo all of the requirements a few days before release.

That sounds stupid, but I have seen it happen. And I’ve seen project managers complain about not meeting deadlines because of it.

This problem, compounded by people in charge of development teams who have never seen a line of code in their lives ends up being a real headache in the world of software development.

The only solution, in conclusion, is communication. Constantly commicate with the clientele on the requirements of the application so that way massive restructures can be avoided later. And email and text doesn’t count, in person conversation is the only way to understand which portions of the application are more important than others.

Leave a Reply

Your email address will not be published. Required fields are marked *