Storm development
March 12, 2007
We have heard of extreme programming and agile development, but I don't think I have heard anything about storm development. Yet it exists, and is widely practiced.
Most development methods strive to achieve higher degrees of coordination. Storm development is about lacking coordination.
Most development methods are about rationalizing, chosing the most logical way, contemplating facts, taking distance. Storm development is about rushing blindly into one direction, with your guts gnawing their way through your braincells.
So what is storm development then?
Well, how many times haven't you felt irritation at having to repeatedly go through the same manual steps, wishing to have a tool doing it for you? Or how many times did you have a tool, but one so badly designed or out of purpose that it made your work harder than having no tool at all? The same for a code api?
When placed in a situation like that, there comes a time when you as a developer have to act and solve the problem and (re)write the piece of crap. For some developers it will happen at a very early stage, for others take more time. And for some it never will: they are those who find it easier to twist their mind than to straighten their world.
And now, confess: in which state of mind were you when you started (re)writing the aforementioned piece of crap? Yes? remember the cold fury? the deadly sense of purpose? the rush of adrenaline?
There it is!
You were storm developing.
Storm development is a developer's primal scream of rage against abherent obstacles. It grows out of accumulated frustration and is characterized by a tremendous albeit usually shortlived burst of coding energy.
Surfed properly, this wave of energy can bring rapid improvement to a project.
But most of the time, the whole momentum of it gets lost because the developer didn't take time to think out properly where he was going before wrecking havoc on the code.
In the past years I have become better at recognizing in myself the symptoms of a storm development crisis before it happens. That's a powerfull tool, really. When I know I am close, I can still take a bit of distance and try to plan for it. That makes the ride more likely to succeed.
And sometimes I may even realise in time that the storm would lead nowhere, manage to calm myself and avoid wasting time!
Most development methods strive to achieve higher degrees of coordination. Storm development is about lacking coordination.
Most development methods are about rationalizing, chosing the most logical way, contemplating facts, taking distance. Storm development is about rushing blindly into one direction, with your guts gnawing their way through your braincells.
So what is storm development then?
Well, how many times haven't you felt irritation at having to repeatedly go through the same manual steps, wishing to have a tool doing it for you? Or how many times did you have a tool, but one so badly designed or out of purpose that it made your work harder than having no tool at all? The same for a code api?
When placed in a situation like that, there comes a time when you as a developer have to act and solve the problem and (re)write the piece of crap. For some developers it will happen at a very early stage, for others take more time. And for some it never will: they are those who find it easier to twist their mind than to straighten their world.
And now, confess: in which state of mind were you when you started (re)writing the aforementioned piece of crap? Yes? remember the cold fury? the deadly sense of purpose? the rush of adrenaline?
There it is!
You were storm developing.
Storm development is a developer's primal scream of rage against abherent obstacles. It grows out of accumulated frustration and is characterized by a tremendous albeit usually shortlived burst of coding energy.
Surfed properly, this wave of energy can bring rapid improvement to a project.
But most of the time, the whole momentum of it gets lost because the developer didn't take time to think out properly where he was going before wrecking havoc on the code.
In the past years I have become better at recognizing in myself the symptoms of a storm development crisis before it happens. That's a powerfull tool, really. When I know I am close, I can still take a bit of distance and try to plan for it. That makes the ride more likely to succeed.
And sometimes I may even realise in time that the storm would lead nowhere, manage to calm myself and avoid wasting time!
