Fog Creek Software
Discussion Board




Return of Cringely on refactoring

http://www.pbs.org/cringely/pulpit/pulpit20030508.html

"My objection is less to refactoring than to its overuse," he says.  Bastard, takes the hard-to-fight middle ground.

Of course, before he wrote:
" 'Cleaning up code' is a terrible thing. Redesigning WORKING code into different WORKING code (also known as refactoring) is terrible. The reason is that once you touch WORKING code, it becomes NON-WORKING code, and the changes you make (once you get it working again) will never be known. It is basically a programmer’s ego trip and nothing else."

'non
Friday, May 09, 2003

Well its easy to be against excess, a little harder to define what excess is.

Simon Lucy
Friday, May 09, 2003

Isn't this reasonableness obvious in the language of the original post?

It is obvious that all terrible things are fine in moderation.

If I eat some food and says 'That's terrible' it's obvious that I'm really saying 'I like it, but you can have too much of a good thing.'

Ged Byrne
Friday, May 09, 2003

The example of Paul from Morgan Stanley seems to support the assertions from Extreme Programming. 

According to Cingley a refactoring team caused havoc by checking out his half finished code.  He had checked in the code half finished on Friday, and somebody checked it out to refactor on Monday morning.

Checking in the code half finished on Friday evening - breaking the build.  What would have happened if the programmer became ill over the weekend and was off for four weeks.

A separate team whose job is purely to refactor code.  These people just don't get it.

Ged Byrne
Friday, May 09, 2003

Although Paul does have a very good blog:

http://www.tyma.com/modules/news/article.php?storyid=9

Ged Byrne
Friday, May 09, 2003

Ged,
He did he checked the code in, but he did not break the build.  It was merely unfinished.  If it doesn't break the build it SHOULD be checked in for the very reason you state.  If you head off to some desert island over the weekend, and decide to stay, the code is in the repository.

That being said, I  agree with you that most terrible things are fine in moderation.  Most problems I see violate this in either policy, procedure, or good intent.

Mike Gamerland
Friday, May 09, 2003

He still missed one of the main points of refactoring: you simply don't do it without a full, robust unit test suite. Otherwise you're simply guessing that the code will work the same after you've refactored. And guesswork is what you're supposed to be guarding against.

I think calling refactoring a "fad" shows his bias here. He seems to be coming from the view that refactoring changes working code, and anything that changes working code is bad.  Well, yeah. But software isn't stable -- it's constantly responding to changing requirements. This is where refactoring really shines -- by constantly making small changes to keep your code flexible and robust (and tested!) you're making it possible to adapt to future circumstances that you or your marketing department haven't even dreamed up yet.

Chris Winters
Friday, May 09, 2003

Cringley is not a programmer.  He might not understand how nor why we do refactor as a matter of course.

Refactoring is like keeping your desk tidy.  If you didn't, you'd eventually need two or three desks..

Nice
Friday, May 09, 2003


Ohhh, come on, stop bullying about Extreme Programming and refactoring. "Refactoring" is just a fancy name to a group of techniques that every programmer should do while is developing his project. After the thing is done, it's done.

About the example: the programmer complained that somebody else checked out the code, didn't implied unfinished code checked in. If I'm working on some stuff that might break the build, I don't check in it; but if somebody checkouts the same project, and start doing "refactoring" (ie, moving things around) and it affect my freshly-baked code, I wouldn't be very happy.

My own gold rule about these fancy stuff: never do it except when all your team is composed of superstar programmers. If you have one or two people located in the middle of the Bell curve, better stick to more traditional methods.

One thing: every one owns the code? Oh boy, I don't want to be there again.

Leonardo Herrera
Friday, May 09, 2003

It's pointless to explain refactoring to Cringely because he is not a programmer and hence he does not understand the difficulties that can arise with badly writen code. Refactoring focuses on fixing incorrectly written code when you spot it. For instance, if you find duplicate code you should refactor it then and avoid problems down the road. He thinks this has something to do with ego but in reality it's just good practice. In any other industry it would be a quality not a fault. If a mason was building a wall and spotted a badly layed row should he stop now and fix the bad row, or should he wait until he is finished so he has  to tear down the entire wall to fix it?

I actually started writing a detailed rebuttal but then I stopped. Cringely is not a programmer and he deserves no reply. Would you walk into an mechanic's shop and abitrarily determine what practices are good and bad? How about a dentist? What about your local hospital? Cringely would. He knows it all.

Of course too much refactoring can be a bad thing. But so can commenting on things you don't know anything about.

Ian Stallings
Friday, May 09, 2003

[A separate team whose job is purely to refactor code.  These people just don't get it. ]

Amen.

Ian Stallings
Friday, May 09, 2003

Ian,

I think I should critise those mechanics.  When I take my car in for a service they change the oil, even though the old oil was working fine.

They're just wasting my money.

Ged Byrne
Friday, May 09, 2003

"Redesigning WORKING code into different WORKING code (also known as refactoring) is terrible."

I don't agree.  As any 'real world' programmer knows, when a client requests a change, you will change that WORKING code.  All of the sudden it becomes NON-WORKING code.  Whereas, if you would have refactored the working code, you could have implemented the change without breaking the code.

While the term "Refactoring" may be what some see as a fad, it's basically just good programming practice.  This guy is a moran!

shiggins_dev
Friday, May 09, 2003

Not only is Cringely not a real person, but Cringely is actually now a summary of the Joel on Software forum.

Didn't those exact words appear here?

www.marktaw.com
Friday, May 09, 2003

He really is confusing refactoring with the problem refactoring was created to fix. For example, Netscape decided to rewrite all their code because no one wanted to take the time to understand how it worked. He is calling this type of action refactoring.

Bill
Friday, May 09, 2003

"Paul’s boss at Morgan Stanley had the right intent, but he was trusting every programmer at every skill level to not break things, which is simply too scary for me."

Unit tests would address that fright factor for him :-)

Scot
Friday, May 09, 2003

Not allowing programmers to refactor would be like not allowing writers to revise and edit.
Some writers revise more than others, and I suppose some programmers refactor more than others. For me, refactoring is essential, and I was doing it long before I knew what it was. It is not a fad.
Cringely telling programmers how to work is kind of ridiculous.

The Real PC
Friday, May 09, 2003


I saw something like this in a program the other day... Yeah, it was a cobol program, and stuff like this was scattered throughout:

if sub-counter not equal zero
  add sub-counter to total-counter
else
  add +0 to total-counter.

I'm fairly confident I could delete 3 lines without affecting the outcome.  However to my surprise several programmers did argue that I could break it - their reasoning... since it was coded like that it must be a requirement for it to stay like that.

Joe AA
Saturday, May 10, 2003

Joe,

trust the programmers. Unless it is extremely critical for you to shave a few nanoseconds of this thing, leave it alone.

Naah, just go for it. If it works no-one will notice it's gone, and that little wind-up monket inside your brain going "ugly code, ugly code, ..." will finaly be KO'ed.
If it doesn't (who knows, due to some obscure pagination bug or whatever), well ... one more reason to request a full rewrite of the system in which you can try out the latest and greatest astrotecture.
Me, hey, stronger man have been tempted :-).

Just me (Sir to you)
Monday, May 12, 2003

Joe,

In the example given above you could also delete lines 1 and 4 (leaving only line 2).

However, you cannot neccessarily say that it will make no difference.  There may be an existing bug
in the program due to memory allocation which has never caused a problem.  This may be because the space which is being effected lies in a location of some redundant code.  As a result of moving that redundant code (lines 1,3 and 4 in you example) you effectively move the location of the memory leak into some very important code.  According to O'Toole's Law this will effect the maximum no of users just prior to your boss awarding you a pay rise.

If the change is being made as part of some mandatory enhancement then you can justify this by claiming it as part of the upgrade (solution: back out the upgrade until the bug is identified).  If you the other hand a programmer was just trying to clean up the code (and is swearing blind he/she didn't change anything as one probably would) it could turn pretty nasty.

Ben

O'Toole's Law = "Murphy was an optimist"

Ben
Monday, May 12, 2003

*  Recent Topics

*  Fog Creek Home