Thursday, April 2, 2009

God is an agile developer

One thing that greatly bothers me in my current position is that no matter how much work I do each day, nothing is ever accomplished. Every project is kept in perpetual development and feature creep is more common than well...anything that is very common. I code. I honestly do. This is why I haven't written much lately. I have been head down barreling forward. Today I have a reprieve. And I also have feature creep.

First of all I am no starry-eyed dream and I realize that feature creep is to be expected in any project. In fact it should be planned for. For most applications there is neither the time nor the knowledge to flush out every possible area of development. However, planning feature creep should be differentiated from scope and purpose changes. Feature creep should be seen as a way to maintain the vitality of an application while also maintaining its core purpose. If the purpose of an application needs to change, a new project should be rededicated. Salvage what code you can and start over. Sometimes it is easier to jump into the sea than to change the course of a sinking ship. This is because feature creep often devolves into a change in the scope of the application itself, often rendering initial planning moot. Design often follows purpose, even if loosely. So such a change can destroy the initial premises of the design of your application. Of course this may not be the case which is why good employees should be not being let out the door. Thoughtful developers will take the time to decide to salvage or ditch.

Feature creep does not have to be a bad thing if it is incremental and time is allowed for each iteration to run its course. However, feature creep becomes detrimental when it becomes a hindrance to the release of the software. Often at my company, each iteration of a feature results in modification of that feature and the addition of new features. This happens in a purely development, sometimes theoretical place. Unfortunately the view of software is in its totality. Only the perfect idea of the software can be released. This waiting for perfection often adds two things to the project - an invisible deadline and failure.

The deadline vanishes since each new request pushes the software date out further and further. Failure then arises from the inevitable waterfall approach that ends up becoming the de facto development model. So much time goes between project launch and project end that several things happen:
1 - People wonder why this software took so long when it seems so simple
2 - People wonder why things do not behave exactly as they expect

The longer a project goes without business user mediation, the more likely it is that the same users will forget why they have asked for something as well as forget how much they asked for.

What becomes necessary and what becomes auxiliary is blurred since now both are merged into this one application. Unfortunately there is no way to get this time back. Everyone is unhappy and nothing gets done.

Oh and the title? Read the creation story in the bible, if you still don't get it. I can't help you.

No comments:

Post a Comment