Often when I start developing something, I have a strong urge to jump on coding with some primitive design in mind. I guess it's natural human urge to get something working and show it to the world, "Yay! See.. I can!". "Oh! Really", says the reviewer. He thinks of the weirdest possible scenario and says, now tell me how in this world will you support that. Quickest answer which just bubbles out -"This is not the requirement!" and I hear the reply I detest "We are agile, requirements will change tomorrow, do you want to change the entire design for that?".
Huh, and thus I start rethinking and start changing some design, just to realize that now to support that weird stuff, I broke the basic requirement and the day I realize that, am too far into the new thing. So even with quick development; starts the last minute cramping to get things in and at the end of the day I hear the howling - "Just get the damn thing done!!"
Most developers go through this dilemma, especially when we have to develop in "agile" mode and the need to re factor urges the day we put in the first cut.
Now, how I learned to handle it. Having hit with such situations couple of times I finally decided to "grow up" and "get smart" at handling my changes. And nothing could help me more than a simple step of just putting in unit test for my code. I had read about it in school and understood the concept but never really got time to explore it.There is never ever enough time to code, where the heck could I find time to write unit test. But now, I decided, let me take some more time and reveal only when I have unit test green for basic required use case. The fun of feedback process starts, but now I have a mechanism to know that I am not breaking the basic requirement in my ambitious goal to handle all scenario's in my design.
I have defined my 'limus test' and till my test glow green I am ready to incorporate all feedback. This has given me amazing flexibility in my development process and is helping me getting "agile". Have also been reading about "TDD-Test Driven Development", but haven't yet got to the stage of writing test before I start development. That would be an ideal world and would make me a happy developer.
Huh, and thus I start rethinking and start changing some design, just to realize that now to support that weird stuff, I broke the basic requirement and the day I realize that, am too far into the new thing. So even with quick development; starts the last minute cramping to get things in and at the end of the day I hear the howling - "Just get the damn thing done!!"
Most developers go through this dilemma, especially when we have to develop in "agile" mode and the need to re factor urges the day we put in the first cut.
Now, how I learned to handle it. Having hit with such situations couple of times I finally decided to "grow up" and "get smart" at handling my changes. And nothing could help me more than a simple step of just putting in unit test for my code. I had read about it in school and understood the concept but never really got time to explore it.There is never ever enough time to code, where the heck could I find time to write unit test. But now, I decided, let me take some more time and reveal only when I have unit test green for basic required use case. The fun of feedback process starts, but now I have a mechanism to know that I am not breaking the basic requirement in my ambitious goal to handle all scenario's in my design.
I have defined my 'limus test' and till my test glow green I am ready to incorporate all feedback. This has given me amazing flexibility in my development process and is helping me getting "agile". Have also been reading about "TDD-Test Driven Development", but haven't yet got to the stage of writing test before I start development. That would be an ideal world and would make me a happy developer.
