4 ms·

I find this argument smells of rationalisation to me: You admit yourself that building new stuff is much more fun. Say making an old codebase is "just as reward

I find this argument smells of rationalisation to me: You admit yourself that building new stuff is much more fun. Say making an old codebase is "just as rewarding" but in order to actually understand all the legacy you need to put in 2x (or whatever the amount) of work that you'd need to build a new thing. Wouldn't you want to build 2 new things instead? I could never imagine someone on their own accord, going by themselves into a 30-year-old codebase and refactoring it, just to make it "look nice". On the other hand people constantly build new stuff (too much of it really). I think it would be fine to admit that working on new code is more desirable than working on old code. Sometimes the latter needs to be done, but I think most programmers are happy to avoid maintenance work when they can.

jacquesm 14y ago
Building something new is more fun in the beginning. Refactoring an old codebase and making it fly is rewarding when you're done. This is not about cosmetics. Both are fun, assuming you stay in long enough the first will at some point turn into the second, no matter how well your intentions were at the beginning ('this one will be different, this time I'll get it right').
- kami8845 14y ago
  Yeah but programmers are generally not bound to a codebase for life. A friend of mine who works at Google says that he generally works on projects in the "do it new and figure out what it needs to do" phase, while there's other engineers at Google who are very good at the maintenance phase and "keeping stuff running and adding slowly to it". I think that's a very nice way of wording it, but I'd definitely want to see myself in the former group, not the latter.
  - jacquesm 14y ago
    > Yeah but programmers are generally not bound to a codebase for life. If you're young I can see how you might have that impression. But I know quite a few programmers personally that have been working on the same codebase for more than a decade, and even a couple that have been working on the same codebase for 3 decades. The web is still young enough that most people that came into programming through building websites have no idea how long most code bases are alive. There is a neat little proverb here: programs are like children, you can start one in an evening but you'll end up supporting it for the rest of your life.
    - kami8845 14y ago
      Not arguing against the fact that old codebases exist and that people have to take care of them. However I don't agree with glorifying old codebases or putting them as "equal" to working on new stuff. If you're happy doing that, then fine, no one's going to stop you from doing it, but I do think that in general, given the choice, almost anyone would pick building something anew over working on a legacy codebase.
      - jacquesm 14y ago
        > Not arguing against the fact that old codebases exist and that people have to take care of them. ok > However I don't agree with glorifying old codebases or putting them as "equal" to working on new stuff. Ok, so we will disagree on that then. I think that both jobs, new stuff and maintaining old stuff are equally rewarding and are essential skills. If all you can do is make new shiny MVPs you'll never run a business. > If you're happy doing that, then fine, no one's going to stop you from doing it, but I do think that in general, given the choice, almost anyone would pick building something anew over working on a legacy codebase. You won't be given the choice, unless you keep running away from your creations.
      - breck 14y ago
        The neat thing about old codebases, is that even if the code is messy, the problem it solves can be very interesting. "Legacy codebase" is another word for "important codebase". When you're coding, you solve the most important problems first. Thus, in some sense, the older the code base, the more important the problem it solves.
        ams6110 14y ago
        And sometimes the code is actually quite good (not saying that's the case in LibreOffice, I have no idea).
        breck 14y ago
        Agreed. I often stumble across some project written in the 80's and think, "wow, that's so much clearer than my code". We have a lot more tools than programmers did back then, but tools are incapable of long term thinking.
ansgri 14y ago
You could do the refactoring to enable yourself to add shiny new functionality to the big old product. In the end you will have a revived mature product with shiny new brass bells and whistles. While that other guy will have nothing more than just another half-usable prototype.
davesims 14y ago
The problem is that in cases like these, invariably the old, crappy code contains documentation and functionality that will never be reproduced by a ground-up re-write. Understanding the old code and rewriting is, in general, just as expensive as refactoring. This is the common dilemma with old codebases like this -- in spite of its horrible, unreadable state, it contains business knowledge too valuable to lose. As far as making the code "look nice" -- you've missed the point. The goal is to make it functional, readable and extensible again, and doing that to a 1M+ line codebase (which I've had to do) can be enormously rewarding, the business value gained more than tangible.
vidarh 14y ago
> I could never imagine someone on their own accord, going by themselves into a 30-year-old codebase and refactoring it, just to make it "look nice". One of my "hobbies" that I unfortunately have too little time to delve into, is to find old code that I want to see live on, especially old Amiga code, and make it live on. Some I "only" make compile for AROS (an AmigaOS re-implementation). Some I try to port to e.g. Linux. Part of it is nostalgia. Part of it the learning experience - code written for a system with 512KB or RAM and a floppy is often structured very differently, and sometimes the approaches are still interesting. Part of it that it is just relaxing to clean up something where all the hard implementation decisions have been done.
RyanMcGreal 14y ago
Someone needs to re-read Spolsky: http://www.joelonsoftware.com/articles/fog0000000069.html http://www.joelonsoftware.com/articles/fog0000000069.html

jacquesm 14y ago

Building something new is more fun in the beginning. Refactoring an old codebase and making it fly is rewarding when you're done. This is not about cosmetics. Both are fun, assuming you stay in long enough the first will at some point turn into the second, no matter how well your intentions were at the beginning ('this one will be different, this time I'll get it right').

kami8845 14y ago
Yeah but programmers are generally not bound to a codebase for life. A friend of mine who works at Google says that he generally works on projects in the "do it new and figure out what it needs to do" phase, while there's other engineers at Google who are very good at the maintenance phase and "keeping stuff running and adding slowly to it". I think that's a very nice way of wording it, but I'd definitely want to see myself in the former group, not the latter.
- jacquesm 14y ago
  > Yeah but programmers are generally not bound to a codebase for life. If you're young I can see how you might have that impression. But I know quite a few programmers personally that have been working on the same codebase for more than a decade, and even a couple that have been working on the same codebase for 3 decades. The web is still young enough that most people that came into programming through building websites have no idea how long most code bases are alive. There is a neat little proverb here: programs are like children, you can start one in an evening but you'll end up supporting it for the rest of your life.
  - kami8845 14y ago
    Not arguing against the fact that old codebases exist and that people have to take care of them. However I don't agree with glorifying old codebases or putting them as "equal" to working on new stuff. If you're happy doing that, then fine, no one's going to stop you from doing it, but I do think that in general, given the choice, almost anyone would pick building something anew over working on a legacy codebase.
    - jacquesm 14y ago
      > Not arguing against the fact that old codebases exist and that people have to take care of them. ok > However I don't agree with glorifying old codebases or putting them as "equal" to working on new stuff. Ok, so we will disagree on that then. I think that both jobs, new stuff and maintaining old stuff are equally rewarding and are essential skills. If all you can do is make new shiny MVPs you'll never run a business. > If you're happy doing that, then fine, no one's going to stop you from doing it, but I do think that in general, given the choice, almost anyone would pick building something anew over working on a legacy codebase. You won't be given the choice, unless you keep running away from your creations.
    - breck 14y ago
      The neat thing about old codebases, is that even if the code is messy, the problem it solves can be very interesting. "Legacy codebase" is another word for "important codebase". When you're coding, you solve the most important problems first. Thus, in some sense, the older the code base, the more important the problem it solves.
      - ams6110 14y ago
        And sometimes the code is actually quite good (not saying that's the case in LibreOffice, I have no idea).
        breck 14y ago
        Agreed. I often stumble across some project written in the 80's and think, "wow, that's so much clearer than my code". We have a lot more tools than programmers did back then, but tools are incapable of long term thinking.

ansgri 14y ago

You could do the refactoring to enable yourself to add shiny new functionality to the big old product. In the end you will have a revived mature product with shiny new brass bells and whistles. While that other guy will have nothing more than just another half-usable prototype.

davesims 14y ago

The problem is that in cases like these, invariably the old, crappy code contains documentation and functionality that will never be reproduced by a ground-up re-write. Understanding the old code and rewriting is, in general, just as expensive as refactoring. This is the common dilemma with old codebases like this -- in spite of its horrible, unreadable state, it contains business knowledge too valuable to lose. As far as making the code "look nice" -- you've missed the point. The goal is to make it functional, readable and extensible again, and doing that to a 1M+ line codebase (which I've had to do) can be enormously rewarding, the business value gained more than tangible.

vidarh 14y ago

> I could never imagine someone on their own accord, going by themselves into a 30-year-old codebase and refactoring it, just to make it "look nice". One of my "hobbies" that I unfortunately have too little time to delve into, is to find old code that I want to see live on, especially old Amiga code, and make it live on. Some I "only" make compile for AROS (an AmigaOS re-implementation). Some I try to port to e.g. Linux. Part of it is nostalgia. Part of it the learning experience - code written for a system with 512KB or RAM and a floppy is often structured very differently, and sometimes the approaches are still interesting. Part of it that it is just relaxing to clean up something where all the hard implementation decisions have been done.

RyanMcGreal 14y ago

Someone needs to re-read Spolsky: http://www.joelonsoftware.com/articles/fog0000000069.html http://www.joelonsoftware.com/articles/fog0000000069.html