4 ms·

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

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.
  - chris_wot 14y ago
    From what I can tell, the UNO code is very good. But there is indeed massive technical debt in the codebase.
davesims 14y ago
Heh -- stick around, kid. :) Those shiny new greenfield codebases, so full of promise, perfect architectures and unfettered extensibility, can turn into slow-moving, spaghetti-code Leviathans in a matter of weeks. It's not just the decades-old, massive LOC codbases that provoke this dichotomy: chances are very good that the code you're working on right now, that gorgeous, sleek, sexy code -- will be staring at you with its cold, incomprehensible dead eyes within the year, asking you how, how did it come to this, how did you neglect me so, and why do you hate me now? OK, or maybe not. But it can happen, and it does, all the time, in really good shops with very experienced coders using all the right techniques and best intentions. I know. Dear God, I know. Of course anyone would rather bootstrap new code and feel the thrill of new object models, shiny, hip new libraries breezing through their editors. But until you've experienced both sides of the equation, the long-term consequences of technical debt growing through a codebase like some kind of...virus...you'll not know how important the second-order effects of refactoring, TDD, and truly clean code really are.

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.
- chris_wot 14y ago
  From what I can tell, the UNO code is very good. But there is indeed massive technical debt in the codebase.

davesims 14y ago

Heh -- stick around, kid. :) Those shiny new greenfield codebases, so full of promise, perfect architectures and unfettered extensibility, can turn into slow-moving, spaghetti-code Leviathans in a matter of weeks. It's not just the decades-old, massive LOC codbases that provoke this dichotomy: chances are very good that the code you're working on right now, that gorgeous, sleek, sexy code -- will be staring at you with its cold, incomprehensible dead eyes within the year, asking you how, how did it come to this, how did you neglect me so, and why do you hate me now? OK, or maybe not. But it can happen, and it does, all the time, in really good shops with very experienced coders using all the right techniques and best intentions. I know. Dear God, I know. Of course anyone would rather bootstrap new code and feel the thrill of new object models, shiny, hip new libraries breezing through their editors. But until you've experienced both sides of the equation, the long-term consequences of technical debt growing through a codebase like some kind of...virus...you'll not know how important the second-order effects of refactoring, TDD, and truly clean code really are.