Reading software development news sites and blogs, you’ll undoubtedly come across a lot of talk about agile development.  In the web world, especially where turn around times are fast and the technology changes even faster, this approach makes a lot of sense: limited documentation, rapid prototyping, a focus on a functional product rather adhering to rigid design specifications.  In a world where most of the work is done in a scripting language anyway, and the codebase itself isn’t necessarily that large, it seems logical to jump on this sort of process.

The inherent problem with the agile approach is the kind of developer that’s likely to be attracted to it.  The one who doesn’t like to do a lot of work, doesn’t like to document, and really just likes to write a lot of code.

Now, as a software developer, there’s nothing wrong with being lazy.  Why worry about pointer math and explicit memory management if you can have a garbage collector do it for you?  Why go through the hassle of creating value objects for your model if you can have an ORM take care of those details?  In fact, computer science students are taught from the ground up to NOT reinvent the wheel unless you have a damn compelling reason to do so.  Software sort of builds on itself in this way.

However, the laid-back mentality that applies well to the actual programming doesn’t lend itself well to the actual business of creating software, ie, the software engineering field, where engineering is application of math, physics, biology, insert-ology-word-here to solve some problem.  Where development of the code can rely on other code, the development of the overall solution still requires that everyone involved does the legwork to make sure you’re actually building the right software.

So far, in my admittedly limited development career, I’ve always worked in an environment that went with an agile approach, or at least claimed to.  In a situation where it’s a small work place, say one or two people, the level of accountability required really isn’t that high.  It’s me and another guy, and if there’s some kind of question involving the design of a project then I just walk down the hall and talk to him about it.

But once there’s more people in the mix, say 4 or more, and you have multiple people working on a project, the process, agile or not needs to thought about more.  In this sort of situation, you might have more than one project going on at once, and everyone is working on some subset of problem (the engineering of the solution).  Now there’s probably someone who’s the project manager, and he needs to communicate requirements and design to the other people on the team.  If everyone’s in the same office at the same time this might work, but in my experience it’s not.  The system breaks down.  People don’t know/understand the scope of what’s going on.  There are components that need to be integrated with others and there isn’t an email to be found that has the detail of how each thing works.  Frustration ensues, deadlines get pushed back, and ultimately, while the project might not be a failure the product isn’t what it could have been.

The point is, that the agile approach isn’t bad.  I still prefer it to a waterfall style approach where you’re stuck in a rigid process that’s inflexible and requires a ton of other artifacts aside from the actual code.  The problem with the agile approach is that you actually have to take it seriously as a process, not just a way to avoid writing extra docs.  If you call yourself agile you still need to gather requirements accurately, you need to keep the customer close at hand, and you absolutely need to be rapidly prototyping and be getting constant feedback from the customer.  You need to be doing lots of user testing.  In essence, you need to many many many releases.  The goal shouldn’t be to shoot for version 1.0, instead you should shoot for every point release until 1.0.  Version 0.1 should be a reality and it should be looked over with the same scrutiny as you plan to do for the final release.  The point is that you can’t call yourself agile unless you really are being agile.