Take it slow if you need it fast!!!
Creator of RoR, David Hansson has posted his good comments about taking things slowly. He has produced some really great stuff in recent past , so based on that - one should give weight to whatever he says. He also suggests to delay *Refactoring* as khurram inquired in his post. I am pasting some really catchy exceprts from David's post
" As a programmer in this small shop, I’m constantly reminded of what happens when I try to go faster by ignoring broken windows. It doesn’t work! You can postpone that refactoring or those tests or this automation for only so long before it starts to hurt both motivationally and economically. But its exactly at that point, when the hurt is pressing, that its the hardest to step back.
In the moment of pressure, it’s incredibly easy to commit the fallacy of thinking that you “don’t have time to do the right thing”. That’s a big warning sign and should condition your brain to slap you when the thought pops into your head.
The reason, of course, is that no business and no project lives or dies by what you do today, but rather as the result of your actions over a longer stretch. This goes for any activity, not just programming. Are you answering the same question over and over again in customer support? Inline the answer at the point of trouble. Or otherwise adjust to be self-explanatory..........................."
Well, folks last paragraph of David's post really made my day. I do agree with him. Over the period of time i have learnt that everybody invovled in crafting softwares could craft a 'Lite' process to fit to his/her needs and there is a lots of buzz going on about this. As in; KIS( Keep it Simple) with small teams, quick releases and NOT writing functional spec ( Rather writing a story that should describe *Run-Time reuirements* and it should not be more than one page , don't confuse it with User-Stories ). Some people also suggest to write stories that encompass both *build-time* and *run-time* requirements. Well , this view would definitely be interesting because that would might lead you to first understand the business process, second is to improvise that business process( as they say Business-Process Reengineering) and then start modelling. Eventually or allow me to say 'essentially' this could *cut the chase* , if you know what i mean [:)].By the way, folks i have really heard interesting stories about implementation of Businesss-Process Reengineering in one of the largest telecomm providers of Pakistan. However, thats a different story altogether [:D] so some other time [:S]