Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • by ziggy (25) on 2002.04.15 8:26 (#6979) Journal
    It's harder to read code than to write it.

    This is why code reuse is so hard. This is why everybody on your team has a different function they like to use for splitting strings into arrays of strings. They write their own function because it's easier and more fun than figuring out how the old function works.

    Like most of what Joel has written, there is a lot of truth to this, but many of these observations are not as universal as he would have you believe.

    First off, I strongly disagree that any principles about programming learned at Microsoft uniformly apply to the rest of the industry as a matter of course. Lots of what Joel writes about wreaks of the kind of work done by masses of programmers-posing-as-smart-people that typifies much of the stories about programming at Microsoft. I've had the extreme pleasure of knowing many really great programmers who continually demonstrate that a good rewrite offers more maintainable and functional code to replace a larger body of buggy, complex code that's impossible to maintain.

    Secondly, my own personal experience is full of cases where rewriting a piece of software (typically less than a whole system or subsystem) was a much more economical and strategically sound way to proceed. "Novelty value" and "coolness factors" weren't part of the discussion. Sometimes we did rewrite/refactor some code; other times we burnt up lots of effort and energy over a period of weeks or months in maintaining a really bad piece of software.

    This is by no means a justification to refactor or rewrite at every opportunity. I see the impulses Joel has mentioned; the urges to rewrite everything are about as unhealthy to maintain existing code simply there's a significant amount of prior investment in it.

    • When I first read that piece a couple of years ago, I had similar thoughts, that Joel went a bit overboard. However, I agreed with him in the general sense. Later that year when we decided to rewrite Perl, they were brought to mind again. Frankly, I've never been able to think too deeply about the purpose of Perl 6 without thinking about that Joel Spolsky piece. Thanks for the link, Nat. :-)
      • It's almost 2 years later, and I can say with conviction that Perl6 isn't a rewrite of Perl5 as much as it's a rethinking of Perl.

        Perhaps that's why it's causing The Fear in so many people...

      • Yup, I thought of perl6 too. But the basic problem I have with his article is how unscientific the premise is. There have been some spectacular "rewrite from scratch" failures. And some spectacular "rewrite from scratch" successes (NT, .NET, perl5). Therefore rewriting isn't always bad, therefore Spolsky's hardline is full of shit. And, even worse, useless. If rewriting from scratch isn't the only variable to consider, what are the others? He doesn't say.


        • Yeah. He says a lot of things that are great to keep in mind when deciding what to do with your old code, but you gotta take it with a grain of salt.