"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. Cleaning up code, which generally does not occur in nature, is a prime example of amateur Open Source software.

Is it just me or is Cringely missing the point that the more routines which share common code which does work, the less bugs? His thinking seems to be indicative of an big up front design kind of thinking - even this thinking can reveal areas which could benefit from refactoring. Thoughts?

Konrad
Friday, May 2, 2003

I haven't read the article, but refactoring code is safer than almost any other method of improving the quality.

Like everything else, though, you don't do it blindly.

As for cleaning code...

The number of times I've walked into projects in various stages, seen the build and asked 'So what's all these warnings then?' and got the response 'Oh they don't matter, it works anyway'.

That, I would call amateurish.

Simon Lucy
Friday, May 2, 2003

Konrad,

Do you have a link for the quote. I'd like to read the full article.

He clearly understand that there is a big difference between rewriting working code and refactoring.

Is the effectiveness of open-source code another example of its lack of professionalism?

Surely if these people were professionals, they'd make sure that :

i) Nobody else could understand their code (IP don't you know)

ii) Theres plenty wrong to keep the maintenance contract healthy.

Ged Byrne
Friday, May 2, 2003

When I read his article, I thought about emailing him, but blah. Let some company go out of business because the ceo listened too closely to Cringely. Entertaining gossiper, but proves a little knowledge is a dangerous thing. "the changes you make (once you get it working again) will never be known" -- I'm glad this is still an industry where cvs is a competitive advantage.

anon
Friday, May 2, 2003

IMHO there are a lot of reasons to refactor, but (I think) the most honorable is to make the code more maintainable by others.

Refactoring seems to get broadly interpreted (by some folks) as "rewriting code without changing the interface." This ignores the fact that real refactorings follow logical transformations that guarantee that behavior does not change or changes only in well defined ways. Cringely is probably talking about the broad interpretation

anon
Friday, May 2, 2003

Uhhh... COMMON SENSE REALITY CHECK, folksies.

Cringely is a writer. Cringely is NOT a developer.

Cringely has his own virtual directory under www.pbs.org. That makes him kind of cool.

Cringely may think he is a rennaissance man.

Cringely is talking at much more than arm's length about the logic, rationales and processes involved in a trade and profession in which he is not a full time player.

He has a right to his opinion. But it's not informed by actual experience.

How many times have any of you been whipsawed by some feeb in your organization who wanted to tell you how to write your code. Oh, gee, that geek has tunnel vision. All he cares about is code. He doesn't see the bigger picture. That stupid idiot savant coder. JUST a coder. I will tell him and everyone else what he should do. WHAT? ME WRITE CODE MYSELF? I am too good for that. But I am so much smarter than a stupid f***head mere coder that I know what is best, not the lowlife coder.

And the beat goes on. Opinions are exactly like assholes, everyone has one, and they all stink.

Bored Bystander
Friday, May 2, 2003

Did he put his foot in it? Yes, there is no doubt. The article should a deep level of ignorance about a widely accepted and useful best practice. He just doesn't get it and it's clear that he is not keeping up with the times... maybe he was an ok reporter back in the cobol days working on mainframes but technology changes. The rest of us moved on long ago. Stick a fork in Cringely. He's done.

Tony Chang
Friday, May 2, 2003

When I read that this morning I immediately thought of Joel On Software. Clearly, Cringely isn't right about what he wrote. I think he's probably right in what he "meant" to write, though, which is that it's dangerous to play around with live, working code.

What he doesn't understand though is how hard it can be to maintain code. Poorly written code may work, but that doesn't mean it isn't broken. If it can't be understand by others and if it's extremely fragile, then it's broken.

Do programmers often break "working" code by rewriting it? Sure. But much more often, they go in and fix code that was either poorly design or poorly implemented.

If you haven't read him before, ignore this week's article. This one and the previous one were way under his usual standards. It's generally a very interesting column.

David
Friday, May 2, 2003

I think the key misunderstanding centers around what "cleaned up the code" means. Cringely seems to think that refactoring is all about making the code look better, according to some aesthetic standard.

As I've seen the term used, "clean up the code" usually means "simplify the code, and make it more understandable". This has obvious benefits for ongoing maintenance, but is also a great way to discover bugs in the software, places where the same operation is done in subtly different ways.

Cleaning up code, refactoring, rewriting... who cares, it's just semantics.

Sometimes it's necessary. Do it when it is necessary, but don't try to make it into something else by believing there is real difference in the terms.

This code has been refactored because I typed it with my left hand. This other code has been rewritten because I typed it with my right.

"on the other hand" <hee hee>

Joe AA
Friday, May 2, 2003

It seems to me that Cringely may have recently encountered a specific case in which refactoring was needlessly done at the expense of reliability and he made an overly broad statement based on this one experience. Most of us agree that carefully selected refactoring is a necessary part of any project that has been around for a long time. Projects often expand beyond the limits of their original architecture and incremental change (refactoring) is the best way to redress that.

Nevertheless, putting aside that sweeping generalization about refactoring, he raises an interesting question regarding the goals of open source development and the conflicts that arise between those goals. Open source developers want to contribute usable, reliable software to the rest of us. But also they are interested in solving programming problems in the most elegant way. Usually those goals are in alignment, but what about the times when they are not?

We are going to spend the next 10 or so years solving and re-solving the problems that lie behind providing the applications that are currently on everyone's desktop. Open source is the only way that best practices for coding these solutions can emerge. How that goal coexists with delivering stable, reliable software is an interesting question to ask.

Ran Whittle
Friday, May 2, 2003

Stepping in too, I agree with Anon and

Refactoring, as he describes it, is a bad investment. How many companies would change working code in production without a business need? How long would you stay employed if you checked out production modules and made "cleaning up code" changes without a need?

Not changes for efficiency or usability or maintainability (another form of efficiency), I (and I believe he) are referring to code that is updated and when you diff it, shows inconsequential or worse significant changes which result in no functional change to the above three. "Bob" just thought this "flowed better."

But it is the project's code, they can do what they want! Absolutely, and therein lies the danger. You use xyzdiff and a new release comes out. What does "cleaned up code" mean? Does it mean you can trust it? Do I spend time reviewing the code itself?

Consider painting a room. Three months later, you decide to paint one wall again, the same color blue. Now you justify the work by saying that you think you could have done it better, gotten a little closer to the ceiling or not as close to the door. In the end, you are done and what has changed? Well, now you are a little closer to the ceiling and farther away from the door. Now, would you expect to be employed as a painter taking this type of approach?

Now for some comments on comments:
- Cringely is a pseudonym. OK, there may be a real one, but this guy is not the original. Finding his real identity is a solution left to the reader. ;-)
- Bored is incorrect. This one was a developer and access to some of the best in the industry gives him insight. Not that it makes him right, but he's not your cube mate commenting on Constitutional law.
- While he is annoying at times, aren't we all?

Mike Gamerland
Friday, May 2, 2003

He has a good incentive to write something that people find controversial and will talk about. While he may not have consciously written something he totally didn't believe, I think he's willing to slip up a bit. A balance of positive and negative word-of-mouth.

Wow, is that for real about Cringley being a psyeudonym? You've got to be kidding me. Man, I feel like i've been punched in the gut. Wow. ;)

I generally enjoy "Cringley's" articles, but the "refactoring is terrible" thing is clearly a case of a man speculating on an issue about which he has no clue.

Crimson
Friday, May 2, 2003

Infoworld has had several Cringelys

I beleive the PBS Cringely is one person, who is an Ex-Infoworld Cringely.

Keith Wright
Friday, May 2, 2003

The funny thing is, he says that refactoring breaks code.

To do real refactoring, unit tests are REQUIRED. If you've got good tests, and they all pass, you know you haven't broken anything. Simple.

Chris Tavares
Friday, May 2, 2003

[To do real refactoring, unit tests are REQUIRED. If you've got good tests, and they all pass, you know you haven't broken anything. Simple. ]

geez, I thought nobody was going to mention this. Who on earth would refactor without solid unit tests already written? You might as well be driving through fog at top speed, knowing that your "successful" because you haven't killed yourself yet.

Ian Stallings
Friday, May 2, 2003

Also refactoring should be a constant, not an end of project or post-project clean up.

"defects fixed by refactoring:

Unify duplicate code
Make the code read better (typically introducing more "why")
Remove unused indirection
Isolate existing logic from a needed change
Replace one algorithm with another
Make the program run faster"

- Kent Beck

But as with any programming technique it's use has to be weighed as a decision with consequences. if the potential pitfalls outweight the benefits then it's not a good idea. Rules like "Refactor Mercilessly" are no substitute for plain old common sense.

Ian Stallings
Friday, May 2, 2003

Some great points made. I've done "refactoring", but its never been out of "vanity" or to make code "cleaner". I've done refactoring strictly when scope changes after a working product is in place. When that occurs, you have no other choice but to either rewrite from scratch (i've tried that before and it sucks) or refactor. Say what you will about requirements and such, but scope does change, and sometimes it will change so drasticly that some major overhauling is required.

Vincent Marquez
Friday, May 2, 2003

I don't understand why there has been so much attention paid to that part of the Cringely article. It was not a main theme and, as others have pointed out, it was by a journalist, not a professional developer.

Apart from that, I thought the rest of the article showed insight. His categorisation of open source as ranging from amateur to professional is perceptive, and a useful contribution.

Friday, May 2, 2003

The statement would be fine if you just took out the refactoring line. Refactoring was created to avoid the exact problem he is talking about, people rewriting code from scratch because they don't like the style or don't want to take the time to understand it.

Bill
Friday, May 2, 2003

"And it was Microsoft that, by its arrogance and conspicuous commercial success, gave the free software movement a bogeyman against which to rail. "

Ah, I can't criticise too much because he does support one of my eariler posts.

Ged Byrne
Saturday, May 3, 2003

Haven't any of you ever seen PLANE CRAZY on PBS? The guy just hangs it all out there, letting camera crews film him completely fucking up building an airplane of his own design. The closest thing to watching a train wreck on TV that I've seen. And he sells copies on his web site!

The thing about Cringely (or Mark Stevens) is that he just writes off the top of his head. If something appears to be the greatest thing since sliced bread, he'll say so. And print an apology two weeks later when someone points out to him that X can't be built, for some reason that would be obvious to a first year CS student. (And the guy has a master's from Stanford!)

So I read him for interest, but take everything he says with a boulder of salt. (He also was employee 12 or so at Apple.)

Contrary Mary
Saturday, May 3, 2003

Do we really have bad advice here?

Joel says to never throw out code and refactoring is the way to go.

This guy says, refactring is a waste of time, and is stupid?

Well, actually, they both are right, and both are giving out sound advice.

There is absolute no reason to go in a meddle with old code that works just fine. I have code running from 1983 that is used in several countries around the world. That is 20 year old code. Some of that code has NOT been changed since back then (a few bug fixes, but I have a big ego, and most of it is really good bug free!). In fact, it really is about as bug free code as you can get.

Actually, some of that code is ugly. I mean real ugly. The main program was actually “input” program that was used to transfer data via serial cable from a bunch of Radio Shack computers . All those variables and code eventually morphed into a forms development package (I had hard coded database fields defs for the transfer at that time). Amazing, the main program module to this day is still called INPUT (in capital letters to boot!).

(this is a forms application development package for Pick multi-valued databases if you are wondering).

Anyway, my whole point here is that if you have code that is not being modified very much at all, and in fact if little or no maintenance is being done on that code, then why refractor to make it look good? There is absolute no reason to muck with that code and introduce bugs. So, in this regards, refactoring just to make something look better is really dumb.

On the other hand, if the code is costing valuable maintenance dollars, and developers are having a hard time working with the code, then sure, it is time to refractor. I mean, code does not rust, and if it runs fine, then why bother?

So, I think is sound advice to leave good reliable running code alone. If developers start mucking around with some code that has no business be changed, then yes, you are asking for trouble. Further, refracting code does involve some risk. However, it certainly involves a heck of a lot less risk then a code re-write (that is Joel’s point now).

So, obviously, refracting is done for some reason, and not just the sake of ego. It is this type of non useful refracting that the author seems to complain about, and I have to agree.

In fact, the very reasons why most programmers are tempted to throw out code are the exact same reasons why some code needs to be mucked with, and “cleaned up”. That reason is much to do with ego, and the fact that other peoples code is hard to read. So, in fact both Joel and this author are saying the EXACT same motivation exists here for doing the wrong thing!

The real rule here is common sense. Some types of re-factoring are also VERY low risk (like indents in code, and adding comments/documentation to the code system).

So, mucking with code is just as dumb as throwing out code when it should not be done, and that is surprisingly a large amount of the time.

Albert D. Kallal
Edmonton, Alberta Canada
Kallal@msn.com

Albert D. Kallal
Saturday, May 3, 2003

The rule that I learned in my rather limited experience is "don't touch code that works".

Now, as it has been pointed out, and as the "theory" of refactoring puts it, there may come times when you really need to change that code (too difficult to maintain, etc). Then, refactoring is less bad than any other form of modifying and cleaning up the code. But still, rule number one should be not to touch it unless you absolutely have no other way around it.

The thing that people should be told is that yes, your code is ugly, and you think that it should be rewritten or refactored into a nice clean mathematical wonder. But remember that most of the "big name" software that runs, and runs very reliably, uses code just as ugly or possibly much uglier then yours. And nobody's refactoring _that_.

Dimitri.
Saturday, May 3, 2003

Code should be refactored while you're developing it. After it's finished and is being used, don't refactor it without a good reason. Maybe that's what Cringely meant. The best time to refactor is before investing a lot of time in testing, because if you refactor extensively then it will have to be tested again.
But Cringely's statement gives the wrong impression -- that refactoring is a bad thing. Refactoring is what makes code healthy and resilient, as well as beautiful.

The Real PC
Saturday, May 3, 2003

He did imply that it was code that was being used. That's the difference as I see it. Code that is being used has been "released" at least once. If you have to refactor now, you really should be asking yourself questions as to why it wasn't done earlier.

Besides, I don't believe in any blanket rules that are set in stone, they are merely generalizations at best. Blindly following any given dogma has it's own can of worms, best left unopened.

Alex
Sunday, May 4, 2003

The difference between commercial & opensource is in general pretty large. What's professional for one is unprofessional for another.

The article claims: "the changes you make (once you get it working again) will never be known." That statement ignores all the work on tools surrounding refactoring. Unit testing, refactoring IDEs, CVS. Even if he claims those tools are immature, they won't mature unless people are "unprofessional" and use them.

Also, there's an underground economy where people rip or learn from opensource code. If the code is internally better, it's easier to use for other projects. This isn't visible to most people.

In fact, the "consumer" of most opensource is another programmer, who definitely does regard clean code as a Feature.

Tj
Sunday, May 4, 2003

btw, I think people who work on those apache projects could have a good view. I often hear that one or another of their projects is hitting redesign for the next version. Maybe they can talk about how much doing this fails or succeeds.

Tj
Sunday, May 4, 2003

I think what's bad are blanket statements. Just as Cringely's statement was (I didn't read the article) bad, so are people who just out and out disagree with it.

www.marktaw.com
Sunday, May 4, 2003

What Cringely was criticizing in the article was a certain type of Open Source Programmer that produces something and then just dries up. He plays around refactoring or tidying up code unnecessarily because he doesn't want to do anytning more ambitious, and because the particular piece of Open Source has become his little baby, and he feels he ought to keep grooming it, instead of seeiing it as part of a contribution to the outside world. Somewhow he let his attack against this turn into an attack against refactoring in general.

Actually it wouldn't be a bad idea if he "cleaned up" his article :)

Stephen Jones
Sunday, May 4, 2003

Cringely, if I recall correctly (oh, the years...) was "created" to fill the spot left when John Dvorak left Infoworld. This was (again, IIRC) in the same timeframe in which they went from a "real" (buy it on the newstand or pay real money for a subscription) to a "controlled circulation" (i.e., advertiser paid/free subscription) model.