On 10/27/07, Sean Corfield <[EMAIL PROTECTED] > wrote: > > > On 10/27/07, Sam Larbi <[EMAIL PROTECTED]> wrote: > > On 10/27/07, Barry Beattie < [EMAIL PROTECTED]> wrote: > > > I used to be but I'm taking a more pragmatic approach now-a-days. > > > Sending code into the big bad world, never to see it again, and having > > > my reputation rest on it's success or otherwise. Get it right, get it > > > out. > > I'm not sure what you mean by that. Could you explain? (I know its off > > topic from your original post, which is why I changed the subject, but > I'm > > interested nevertheless). > > Without wishing to speak for Barry, I suspect he means that continuous > improvement is a luxury you can afford when you will be working on the > code throughout its lifetime. If you have just one shot to write code > and release it to a client - and you won't get a chance to improve it > after that - it had better be good, out of the gate! > > I agree. Code I write for myself and my startup (and to some extent > for open source projects where I'll continue to be involved), I write > fast and then refactor. Code I write for clients gets refactored > during my time on the project but I aim to have it be as good as > possible before I have to give it up. > > Make sense?
It makes complete sense. I wasn't trying to claim that because we often /can/ revisit code we can write it sloppily the first time around. I guess I am confused about where we disagree in particular. Bringing back the context of my remark: ------------- Phillip Senn, quoting someone else: > No matter what code I write it always embarrasses me a year or so later. Phillip Senn: Oh wow! What a great life-lesson. I've been pondering lately that 50% of coding should be taking out the garbage. Maybe another 10% should be revisiting / refactoring every 6 months. ------------- My own remarks: I'm a big fan of continuous improvement. When you notice bad code while working on it (or perhaps even near it), make it better. I don't see any purpose in taking out time to go back and beautify ugly code you haven't touched in six months (or more!) though. Wait until you need to work on it, then make it better. If you never work on it again, there was no need to make it better in the first place. ------------- Don't be sloppy, but given that you'll be working on bad code, fix it when you do. The more hacks you keep putting into it, the longer those hacks take and the buggier/more fragile it becomes. Improve it, even if just by a little each time, and soon you'll be writing quick fixes that are good code, not ugly hacks. It doesn't need to apply only to your own code. In fact, I would apply it to any code I work on. Is there still disagreement? If so, where? Regards, Sam --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "CFCDev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cfcdev?hl=en -~----------~----~----~----~------~----~------~--~---
