How not to fail: iterate thrice

November 22, 2008

AppendicitisCome on, it won’t take long. Just squeeze it in with that round of bugs. I’m sure it’ll work just fine. After all, it’s pretty simple isn’t it?”

Whether your team is stuck in the dark ages of waterfall development or has adopted an agile methodology (agile what? read this or this), this thought has probably gone through your head. Unfortunately, it far too often comes out of the mouths of managers.

The problem is that you often end up with unfinished, half working features which bloat the code, distract developers and confuse users. Left unchecked, these can become toxic to the project’s credibility and usability.

This is particularly important for projects with limited budgets, which can run into the wall with a backlog of bugfixes/feature requests (they’re not that different, really). These can hound you for a very, very long time.

The complicated answer? Follow a tried and tested agile methodology.

The simple answer: iterate thrice. Don’t implement anything that can’t fail at least twice.

What does this mean? Release quickly, test it on users, fix the problems, rinse, repeat.

How long does this take? If your users use your software daily, give them at least a week to spot the room for improvement. Increase this time as necessary. If you have a limited budget, never start a new feature unless you have that time before the money runs dry.

At best it’ll be only partly useful.

Worst case: it will come back to bite you.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: