Social Mode

Here we find yet another lively discussion questioning whether Agile Programming is real.

Let’s just tackle the various claims and arguments head on.

The behavior involved and contingencies bringing about leaner development are real.  The name “Agile” is marketing.   The recent economic turbulence reinforces quicker time to market and lower costs.  However, the evolution of software development was/is being shaped even if the economy didn’t stink as a result of changing needs, better tools, and better talent pools.

As for statics claiming Agile has a better methodology – those all need to be qualified by their context.  Creating software in short sprints without extensive documentation doesn’t always lead to fewer defects over the lifetime of a code base, for example.  Often the comparisons of projects cannot be done because the context of project and the eventual life of the software is so drastically different.

Generally all software development involves:

• Shipping code that works “good enough” for intended use (good enough being defined by “criticalness” of the software”)
• Providing documentation for others to understand what the software does (documentation takes different forms, but there is always documentation)
• Fixing stuff that doesn’t work (all software has bugs)

I propose that if you don’t do those 3 things, you aren’t doing software development.  You might be doing  proof of concepts or experimenting, but it’s not software development without those 3 things.

Whether you engage in rapid development, you’ll eventually have to document should you want other people to understand your code. (it might be a series of emails or a wiki, but there will be documentation).  If we do waterfall but the product is missing key features, you’ll sprint to add those at some point.  Users must use the code for you to know if it works.  And so on…  the point here is that no matter how you come at a project, software development has to have certain things accomplished or it doesn’t produce workable, usable, sellable code.

Furthermore, “agile” probably happens through waterfall processes and vice versa.  You can’t very well build an entire code base from scratch and never do a build and check.  And you can’t very well scrum your way to a marketable and packaged code base.

In fact, I challenge anyone to find me a project/product completely built in one method over the other.  One of the commentators in the linked article brings up the example of salesforce.com and their service building.  They do employ some agile approaches now but the core wasn’t built via agile.

Sure, “Agile” is a nice marketing concept AND it is a useful label because it helps people communicate.  If there’s one challenge that plagues all software efforts, it’s communication.  The communication most likely to go haywire is the context in which people are developing.  So having a company, client and team understand when phases of a project are in “agile”mode is a useful thing to keep people playing by the right rules for the situation.  The term also allows us to encompass a long description in a simple word.  That has a certain economy to it.

Agile is something.  Is it something new, probably not.  Is it something you use, yes, you might not have had one word for it yet. Now you do.

Read Full Post »