Re: Refactoring process model,

I think that refactoring, like testing, can be done to benefit the
programmer or the customer. I think that programmer refactoring, like
programmer testing, is about safety. And, I think that corporations have
proven time and again that profit can trump safety. So, it is our job as
professionals to tell them to go shove it. We aren't going to do things as
programmers that make us less safe.

I also think that the *technique* of refactoring can be used to achieve
some non-functional customer goal written on a storycard (or elsewhere.) It
is important to me to keep these two things separate for the same reason
that it is important to keep customer and programmer testing separate (and
acknowledge that neither is truly optional.)

On Sun, Oct 28, 2012 at 12:54 PM, Amir Kolsky <[email protected]> wrote:

> **
>
>
> Sorry if I was not clear - what I was saying is that you never just
> refactor
> to improve design. Improving the design is a means to an end -- even simply
> cleaning up the code after you worked with it to create clarity or
> eliminate
> redundancy is done to improve maintainability.
>
> There is always a business motivation.
>
>
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On
> Behalf Of Adam Sroka
> Sent: Sunday, October 28, 2012 12:51 PM
> To: [email protected]
> Subject: Re: [refactoring] Refactoring process model,
>
> Sure, but if you simply say that you can use refactoring to improve any of
> these aspects you lose an important distinction. In XP we refactor all of
> the time, and that refactoring is explicitly for the purpose of making the
> code easy to understand and work with (i.e. "good design.") We might also
> refactor to improve performance or some other customer-facing quality, but
> to do that we first need to work with the customer to get a realistic
> threshold, write tests for it, determine if the current performance is
> acceptable, use a profiler to find out where to optimize, etc. That's a
> different activity from mere refactoring.
>
> On Sun, Oct 28, 2012 at 12:42 PM, Amir Kolsky <[email protected]>
> wrote:
>
> > **
>
> >
> >
> > Performance, extensibility, scalability....
> >
> >
> > -----Original Message-----
> > From: [email protected] [mailto:[email protected]]
> > On Behalf Of Adam Sroka
> > Sent: Sunday, October 28, 2012 12:39 PM
> > To: [email protected]
> > Subject: Re: [refactoring] Refactoring process model,
> >
> > I get what you are saying. I suppose there are a number of
> > non-functional aspects that can be improved through refactoring:
> > comprehensibility, modularity, maintainability, etc. The simple design
> > model still works best for me.
> >
> > On Sun, Oct 28, 2012 at 12:30 PM, Amir Kolsky <[email protected]>
> > wrote:
> >
> > > **
> >
> > >
> > >
> > > The point is that you don't refactor to improve the design. You
> > > refactor to improve the maintainability of your product. This is a
> > > behavioral aspect of the product -- an ility, not functional.
> > >
> > >
> > > -----Original Message-----
> > > From: [email protected]
> > > [mailto:[email protected]]
> > > On Behalf Of Adam Sroka
> > > Sent: Saturday, October 27, 2012 10:03 PM
> > > To: [email protected]
> > > Subject: Re: [refactoring] Refactoring process model,
> > >
> > > The only one that matters.
> > >
> > > On Sat, Oct 27, 2012 at 3:07 PM, Amir Kolsky <[email protected]>
> > wrote:
> > >
> > > > **
> > >
> > > >
> > > >
> > > > And the name we give this ility is?
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: [email protected]
> > > > [mailto:[email protected]]
> > > > On Behalf Of Adam Sroka
> > > > Sent: Saturday, October 27, 2012 2:51 PM
> > > > To: [email protected]
> > > > Subject: Re: [refactoring] Refactoring process model,
> > > >
> > > > To make the design simpler -- so it has less duplication, is
> > > > clearer, and has no unneeded parts. Thus it should be easier to
> > maintain.
> > > >
> > > > On Sat, Oct 27, 2012 at 2:25 PM, Amir Kolsky
> > > > <[email protected]>
> > > wrote:
> > > >
> > > > > **
> > > >
> > > > >
> > > > >
> > > > > You do not refactor, that is change the design, just for the
> > > > > sake of
> > > it.
> > > > > You
> > > > > set out with the goal of improving SOME ility -- why else would
> > > > > you change your design? The same hold for process refactoring.
> > > > > So, here's a question to the original poster -- what are you
> > > > > trying to accomplish?
> > > > >
> > > > >
> > > > > -----Original Message-----
> > > > > From: [email protected]
> > > > > [mailto:[email protected]]
> > > > > On Behalf Of Adam Sroka
> > > > > Sent: Saturday, October 27, 2012 12:27 PM
> > > > > To: [email protected]
> > > > > Subject: Re: [refactoring] Refactoring process model,
> > > > >
> > > > > We refactor to improve the design. We optimize to improve
> "ilities."
> > > > > These are separate activities. The end goal is to have the best
> > > > > design that meets the customers needs.
> > > > >
> > > > > It is true that a given refactoring may preserve behavior but
> > > > > not performance (or other qualities.) That's why we write tests
> > > > > for these and when they fall outside an acceptable threshold we
> > > > > optimize them aggressively.
> > > > >
> > > > > On Sat, Oct 27, 2012 at 11:51 AM, Amir Kolsky
> > > > > <[email protected]>
> > > > > wrote:
> > > > >
> > > > > > **
> > > > >
> > > > > >
> > > > > >
> > > > > > Well... Refactoring a system means changing its internal
> > > > > > structure without changing its behavior. I would guess that
> > > > > > for a process with a specified input and output, you can
> > > > > > change the internal steps without changing the outcome.
> > > > > >
> > > > > > The problem with the definition of refactoring is that what is
> > > > > > construed to be the 'behavior of the system' really means the
> > > > > > 'functional behavior of the system'. This leaves 'ilities' in
> > > > > > an unknown state. Should the performance be the same? The
> flexibility?
> > > > > > The maintainability?
> > > > > >
> > > > > > If you would keep the full behavior of the system intact, you
> > > > > > can't really do any refactoring. So my guess is that by 'process'
> > > > > > refactoring we mean making sure that the outcome is the same
> > > > > > but we get better performance, visibility, quality, etc.
> > > > > >
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: [email protected]
> > > > > > [mailto:[email protected]]
> > > > > > On Behalf Of Steven Gordon
> > > > > > Sent: Saturday, October 27, 2012 10:15 AM
> > > > > > To: [email protected]
> > > > > > Subject: Re: [refactoring] Refactoring process model,
> > > > > >
> > > > > > Would refactoring a model mean that the form and organization
> > > > > > of the model is being changed while keeping the meaning of the
> > > > > > model
> > > > unchanged?
> > > > > >
> > > > > > If so, I would need some convincing to believe there is much
> > > > > > practical value in it.
> > > > > >
> > > > > > If not, then I think refactoring would be a very deceptive way
> > > > > > to label what is really reworking a model.
> > > > > >
> > > > > > SteveG
> > > > > >
> > > > > > On Sat, Oct 27, 2012 at 12:37 AM, aishafds
> > > > > > <[email protected]>
> > > wrote:
> > > > > >
> > > > > > > **
> > > > > > >
> > > > > > >
> > > > > > > Hi
> > > > > > > Am planning to do a little research on refactoring of
> > > > > > > business process models. can you please suggest some ways i
> > > > > > > can go
> > about...
> > > > > > >
> > > > > > > Was thinking of a normalization approach to the models...do
> > > > > > > you think this idea can work out ?
> > > > > > > thanks
> > > > > > > looking forward to your suggestions Aisha
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > [Non-text portions of this message have been removed]
> > > > > >
> > > > > > ------------------------------------
> > > > > >
> > > > > > Yahoo! Groups Links
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > > [Non-text portions of this message have been removed]
> > > > >
> > > > > ------------------------------------
> > > > >
> > > > > Yahoo! Groups Links
> > > > >
> > > > >
> > > > >
> > > >
> > > > [Non-text portions of this message have been removed]
> > > >
> > > > ------------------------------------
> > > >
> > > > Yahoo! Groups Links
> > > >
> > > >
> > > >
> > >
> > > [Non-text portions of this message have been removed]
> > >
> > > ------------------------------------
> > >
> > > Yahoo! Groups Links
> > >
> > >
> > >
> >
> > [Non-text portions of this message have been removed]
> >
> > ------------------------------------
> >
> > Yahoo! Groups Links
> >
> >
> >
>
> [Non-text portions of this message have been removed]
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>  
>


[Non-text portions of this message have been removed]



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

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:
    [email protected] 
    [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/