headers
David Vydra | 2 Jan 2004 19:40

Re: Re: lava flows...

I would like add that changing code without informing the customer(s) and
getting their agreement is iresponsible. Customers can be convinced that a
rewrite is necessary if it will allow the system to evolve. At the end of
the day its often a business decision.
-David
www.testdriven.com

>
> Refactoring code that doesn't change is not only in bad taste, it's
> dangerous.  There is no test suite that tests every single
> condition.  At the very least, we don't know whether the code ends
> or not, plus it's hard to account for timing.  Changing the code for
> no reason is irresponsible.
>
> --- In refactoring <at> yahoogroups.com, Jose Bonnet <jbonnet <at> p...> wrote:
> > >>>> It seems to me that "wrapping" should be a last resort, and
> continuing
> > >>>> to engage in the legacy code, simplifying it, removing dead
> code and
> > >>>> unnecessary layers, adding tests and refactoring, should be
> preferred.
> > >>
> > >> The problem here is usually cost: wrapping allows you to
> control how
> > 'deep'
> > >> you may go, and therefore how long will it take (and how much
> will it
> > cost).
> > >> Refactoring should only be at stake if the legacy code
> is 'unwrappable'.
(Continue reading)

Permalink | Reply | 6 comments |
headers
Michael Feathers | 2 Jan 2004 22:12
Picon

Re[2]: Re: lava flows...


Sorry, Mr. Customer.  The code is my responsibility, not yours.  I'll
change it any way I determine is appropriate to give you the features
you want, keep it maintainable, and prevent errors from getting out
into the field.  I'll do these things because I am responsible.

Michael Feathers
www.objectmentor.com

DV> I would like add that changing code without informing the customer(s) and
DV> getting their agreement is iresponsible. Customers can be convinced that a
DV> rewrite is necessary if it will allow the system to evolve. At the end of
DV> the day its often a business decision.
DV> -David
DV> www.testdriven.com

>>
>> Refactoring code that doesn't change is not only in bad taste, it's
>> dangerous.  There is no test suite that tests every single
>> condition.  At the very least, we don't know whether the code ends
>> or not, plus it's hard to account for timing.  Changing the code for
>> no reason is irresponsible.
>>
>> --- In refactoring <at> yahoogroups.com, Jose Bonnet <jbonnet <at> p...> wrote:
>> > >>>> It seems to me that "wrapping" should be a last resort, and
>> continuing
>> > >>>> to engage in the legacy code, simplifying it, removing dead
>> code and
>> > >>>> unnecessary layers, adding tests and refactoring, should be
>> preferred.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Ron Jeffries | 2 Jan 2004 22:15
Favicon

Re: Re: lava flows...

On Friday, January 2, 2004, at 4:12:38 PM, Michael Feathers wrote:

> Sorry, Mr. Customer.  The code is my responsibility, not yours.  I'll
> change it any way I determine is appropriate to give you the features
> you want, keep it maintainable, and prevent errors from getting out
> into the field.  I'll do these things because I am responsible.

That said, Mr Programmer, under what circumstances would you change code
that doesn't have outstanding defects against it, scheduled for fixes, and
that doesn't have outstanding features requested?

Ron Jeffries
www.XProgramming.com
Think!  -- Aretha Franklin

------------------------ Yahoo! Groups Sponsor ---------------------~-->
Upgrade to 128-bit SSL Security!
http://us.click.yahoo.com/qZ0LdD/yjVHAA/TtwFAA/umvwlB/TM
---------------------------------------------------------------------~->

Yahoo! Groups Links

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

To unsubscribe from this group, send an email to:
 refactoring-unsubscribe <at> yahoogroups.com

Your use of Yahoo! Groups is subject to:
 http://docs.yahoo.com/info/terms/
(Continue reading)

Permalink | Reply | 1 comment |
headers
Michael Feathers | 2 Jan 2004 22:38
Picon

Re[2]: Re: lava flows...


>> Sorry, Mr. Customer.  The code is my responsibility, not yours.  I'll
>> change it any way I determine is appropriate to give you the features
>> you want, keep it maintainable, and prevent errors from getting out
>> into the field.  I'll do these things because I am responsible.

RJ> That said, Mr Programmer, under what circumstances would you change code
RJ> that doesn't have outstanding defects against it, scheduled for fixes, and
RJ> that doesn't have outstanding features requested?

Whenever I don't have anything else to do.

Michael Feathers
www.objectmentor.com

Yahoo! Groups Links

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

To unsubscribe from this group, send an email to:
 refactoring-unsubscribe <at> yahoogroups.com

Your use of Yahoo! Groups is subject to:
 http://docs.yahoo.com/info/terms/
Permalink | Reply | 0 comments |
headers
David Vydra | 2 Jan 2004 23:03

Re: Re: lava flows...

Michael,
This is an issue I've been struggling with for a while. I think on some
projects your approach works and its easier just to do it than to ask for
permission, but on others it has to be explicit because the risk and time
involved are too great.  In general, I prefer for Mr. Customer and Mr.
Programmer to be on the same team, to understand each others language, and
make joint decisions.
I have seen 'refactoring' become a negative term in some organizations when
the other stakeholders such as operations, professional services, QA, and
tech support are not properly informed of the extent to which the code has
changed.
-d
www.testdriven.com

----- Original Message ----- 
From: "Michael Feathers" <mfeathers <at> mindspring.com>
To: "David Vydra" <refactoring <at> yahoogroups.com>
Sent: Friday, January 02, 2004 1:12 PM
Subject: Re[2]: [refactoring] Re: lava flows...

>
> Sorry, Mr. Customer.  The code is my responsibility, not yours.  I'll
> change it any way I determine is appropriate to give you the features
> you want, keep it maintainable, and prevent errors from getting out
> into the field.  I'll do these things because I am responsible.
>
> Michael Feathers
> www.objectmentor.com
>
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Keith Ray | 2 Jan 2004 21:48
Picon

Re: Re: lava flows...

I, of course, never advocated changing code for "no reason". I was 
saying that layering code on top of other code is not necessarily the 
best way to add to add new features.

Layering code to make the 'hard to understand' api to be more 
'understandable' API is also not fixing the problem of the 'hard' code, 
because maintenance programmers will have to understand both layers in 
order to made changes.

On Friday, January 2, 2004, at 10:40  AM, David Vydra wrote:

> I would like add that changing code without informing the customer(s) 
> and
> getting their agreement is iresponsible. Customers can be convinced 
> that a
> rewrite is necessary if it will allow the system to evolve. At the end 
> of
> the day its often a business decision.
> -David
> www.testdriven.com
>
>>
>> Refactoring code that doesn't change is not only in bad taste, it's
>> dangerous.  There is no test suite that tests every single
>> condition.  At the very least, we don't know whether the code ends
>> or not, plus it's hard to account for timing.  Changing the code for
>> no reason is irresponsible.
>>
>> --- In refactoring <at> yahoogroups.com, Jose Bonnet <jbonnet <at> p...> wrote:
>>>>>>> It seems to me that "wrapping" should be a last resort, and
(Continue reading)

Permalink | Reply | 1 comment |
headers
Phlip | 3 Jan 2004 03:37
Picon
Favicon

Need help out of a maze...

Refactorists:

I need to randomly generate a maze.

Because Google's more efficient than labor, I found a
program to do it here:

  http://www.charm.net/~shack/java/mazesource.html

(Hit View Source to see the real source. Hit:
http://www.charm.net/~shack/java/maze.html to see
beautiful output, before I ripped out the Applet
stuff.)

The algorithm declares walls around cells in a grid,
where each cell is an integer. One of four bits ORed
together into the integer indicates one of four walls.
Maze building recursively digs into cells, adding
walls until reaching a dead end blocked by an existing
wall.

But that beautiful output and possibly useful
algorithm come at a price: ~40 irritatingly similar
blocks of this shape:

  else if ((r==1)||(r==4))
  {
    if (x+10) /* move up */
    {
      if (path[x][y-1]==0)
(Continue reading)

Permalink | Reply | 13 comments |
headers
Phlip | 3 Jan 2004 03:45
Picon
Favicon

Need help out of a maze...

Refactorists:

Now that we have seen the problem, we must add some
tests, and try to fix it. Hidden inside that
brute-force algorithm might be elegance. Or, I may
have wandered into a ... dead-end.

After compiling maze.exe (or the equivalent), save the
following as a SH script - promote.sh - and run it:

  ./maze.exe 6 99 > map_6_99.txt
  ./maze.exe 6 98 > map_6_98.txt
  ./maze.exe 6 97 > map_6_97.txt
  ./maze.exe 6 96 > map_6_96.txt
  ./maze.exe 6 95 > map_6_95.txt

  ./maze.exe 7 99 > map_7_99.txt
  ./maze.exe 7 98 > map_7_98.txt
  ./maze.exe 7 97 > map_7_97.txt
  ./maze.exe 7 96 > map_7_96.txt
  ./maze.exe 7 95 > map_7_95.txt

  ./maze.exe 8 99 > map_8_99.txt
  ./maze.exe 8 98 > map_8_98.txt
  ./maze.exe 8 97 > map_8_97.txt
  ./maze.exe 8 96 > map_8_96.txt
  ./maze.exe 8 95 > map_8_95.txt

That creates test reference data - a bunch of
pseudo-random maps.
(Continue reading)

Permalink | Reply | 0 comments |
headers
a_juggsbunny2 | 3 Jan 2004 04:29
Picon
Favicon

Want to see me put a golf ball in my ass?

Check me out here
http://www.nudeadultfriendfinder.com/landing.asp?afl=FYHO
If you ever want to chat sometime Yahoo IM me at pinky_soft_lips

------------------------ Yahoo! Groups Sponsor ---------------------~-->
Upgrade to 128-bit SSL Security!
http://us.click.yahoo.com/qZ0LdD/yjVHAA/TtwFAA/umvwlB/TM
---------------------------------------------------------------------~->

Yahoo! Groups Links

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

To unsubscribe from this group, send an email to:
 refactoring-unsubscribe <at> yahoogroups.com

Your use of Yahoo! Groups is subject to:
 http://docs.yahoo.com/info/terms/
Permalink | Reply | 0 comments |
headers
David Vydra | 3 Jan 2004 08:05

Re: Re: lava flows...

Keith,
This is exactly why I suggest that this is a business decision. Will there
be maintenance of this code? Can the company afford the possibility of
introducing bugs into the code no matter how hard it is? What is our context
anyway? There is a gap between a medium size app for a single department and
commercial software that has hundreds of installs. In my current pet
project, ESL, I refactor mercilessly because I have zero installs. At work,
for a public software company, I write lots of wrappers. This is not to say
that we should not refactor large commercial applications, its just that the
marketing story and budget for QA and tech support come into the equation. I
can tell you several stories where commercial software, once rewritten,
simply did not work, and this had devastating effect on the company.
-d

----- Original Message ----- 
From: "Keith Ray" <keithray <at> mac.com>
To: <refactoring <at> yahoogroups.com>
Sent: Friday, January 02, 2004 12:48 PM
Subject: Re: [refactoring] Re: lava flows...

> I, of course, never advocated changing code for "no reason". I was
> saying that layering code on top of other code is not necessarily the
> best way to add to add new features.
>
> Layering code to make the 'hard to understand' api to be more
> 'understandable' API is also not fixing the problem of the 'hard' code,
> because maintenance programmers will have to understand both layers in
> order to made changes.
>
> On Friday, January 2, 2004, at 10:40  AM, David Vydra wrote:
(Continue reading)

Permalink | Reply | 0 comments |

Gmane