Re: Re: Ambiguous Refactoring Solution

2009/9/23 Adam Sroka <[email protected]>
>
>
>
> On Wed, Sep 23, 2009 at 12:37 AM, Olof Bjarnason
> <[email protected]> wrote:
> >
> >
> >
> > 2009/9/23 Adam Sroka <[email protected]>
> >
> > >
> > >
> > >
> > > On Wed, Sep 23, 2009 at 12:20 AM, Donaldson, John (GEO)
> > > <[email protected]> wrote:
> > > >
> > > >
> > > >
> > > > Olof,
> > > >
> > > > > But again - if there is no driving force (fixing errors, adding new
> > > > > use cases), I would wait with refactoring. Of course, one driving
> > > > > force could be the will to learn refactoring..
> > > >
> > > > I'm a little bit worried about this direction. I mean, in the cycle red-green-refactor, we have no motive for the refactoring, other than some nebulous concept of code goodness. So, if you see a class that is too big, and you have some time to spend on improving your code base - then why not?
> > > >
> > >
> > > I empathize with the concern. I think that quality is a sufficient
> > > motivation and for those for whom it is not a motivation we should
> > > seek to change that. For some, this will not work, but if we are
> > > persistent such influences will fade with time (And hopefully, those
> > > individuals as well.)
> >
> > OK maybe I should have been a little clearer.
> >
> > When prioritizing things, improving "old code" should be lower on the
> > list than fixing backlog / doing what the customer asks.
> >
> > If the customer isn't asking something, or the backlog is clear - then
> > why not improve the design of the code?
> >
>
> In general, sans qualification, why not improve the design of the code?
>
> The only answer I can think of, as implied by your words, is that the
> customer is asking for something and that is more pressing.

Yes. But if there is no backlog, and the customer isn't asking, either
the project is "done" or, as I said in another post, there is some
off-synch-time to use to train testing/refactoring (aka design).

>
> So, that is yet another reason (anybody counting?) that we should
> endeavor to keep our cycles short and have plenty of time left over to
> do our jobs right.

Mm there is reason for TDDs last step "refactor". We strive to avoid
the situation "oh jesus I really dislike this piece of s*t code but
other matters are more pressing".

So I guess the next question is: if we've been "good citizen" and
refactored rigorously from start - what should we do with slack time
;)

> 


--
twitter.com/olofb
olofb.wordpress.com
olofb.wordpress.com/tag/english


------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/refactoring/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/refactoring/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:[email protected] 
    mailto:[email protected]

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/