3 ms·

>But I'm game. Give me a problem with 1,000,000 lines of C. But don't expect me to read the C, I couldn't. And don't think I'll have to write 10,000 lines of Fo

>But I'm game. Give me a problem with 1,000,000 lines of C. But don't expect me to read the C, I couldn't. And don't think I'll have to write 10,000 lines of Forth. Just give me the specs of the problem, and documentation of the interface. I could be wrong, but I'd wager that a lot of projects that are 1,000,000 lines of C don't have well defined interfaces or documentation. However, if the author wants to give it a shot, they could try replacing v8 with pure forth. That's a fairly well defined problem, they just have to maintain compatibility with the exposed v8 api.

kctess5 11y ago
I'm not sure the stats on this one, but it seems to be that something with 1,000,000 loc would have to have decent documentation, or it would be totally unmaintainable and wouldn't grow to that size without dying a horrible death.
- protomyth 11y ago
  You would think that, but it can grow without understanding by adding code at the edges which expands then starts the cycle over. A code archeologist[1] would see a central island with bridges to developed islands with more bridges and various ships running between interfaces. Its particularly fun with multiple subsystem teams. Each one builds its own island of code and the bridges are scary. 1) please say that exists
  - TranquilMarmot 11y ago
    I could probably describe my current job as a "code archaeologist"...
  - archgoon 11y ago
    > 1) please say that exists The term 'software archaeology' has been used for a while https://en.wikipedia.org/wiki/Software_archaeology https://en.wikipedia.org/wiki/Software_archaeology And the wiki page suggests there are some consultants in the field. Many programmers trying to understand open source projects will dabble a bit in this.
    - Rusky 11y ago
      Vernor Vinge's novel A Deepness in the Sky has "programmer archaeologists" working on their starship fleets that have thousands of years worth of software going back to "the 0-second of one of Humankind's first operating systems": https://en.wikipedia.org/wiki/A_Deepness_in_the_Sky#Interstellar_culture https://en.wikipedia.org/wiki/A_Deepness_in_the_Sky#Interste...
    - hga 11y ago
      I have been just such a consultant/employee doing this, even started calling it software archaeology some time in the '90s. It's a very painful way of earning money, but there's a whole lot of "poorly documented or undocumented legacy software implementations" out there. Generally effectively undocumented, for many projects start out with some documentation, don't keep it up to date, and by the time you get your hands on the mess it all, including comments, are more a statement of intention at one point in time than something directly and immediately useful.
      - alch- 11y ago
        > It's a very painful way of earning money But.. strangely fun, in a twisted way? I love a blank canvas or a well-written codebase as much as the next guy, but I find that fixing "legacy"[1] codebases can be pretty enjoyable. Slowly figuring out and fixing a "legacy" codebase, to me, is basically solving a giant, complicated puzzle that was left for you by your predecessors. Granted, you're mired in evil gunk from the past, but every time you figure out a small piece of the garbage and refactor it into something nice, you get to feel awesome. Of course, this assumes that you've convinced management that the codebase must be tamed[2] and that this will take time; otherwise you're just fighting with your hands tied. Then again, maybe I'm just a masochist. [1] "Legacy", because people don't like it when you call it "evil gunk from the past that must be destroyed". [2] And it must indeed be tamed, because otherwise it will just grow more and more evil until development grinds to a halt. If management understands this, they'd be crazy to choose the "let the beast grow" option.
        otakucode 11y ago
  - eric_h 11y ago
    I would think that anyone taking on maintenance of a code base that's been under active development for more than 5 years and no longer employs the original developers will necessarily be practicing code archeology.
  - bcbrown 11y ago
    I bet you'd enjoy http://www.amazon.com/Your-Code-Crime-Scene-Bottlenecks/dp/1680500384/ http://www.amazon.com/Your-Code-Crime-Scene-Bottlenecks/dp/1...
    - protomyth 11y ago
      The book title made me think of why I still wake up at night from reliving a conversation I had with a developer when I was doing an interface, who was so proud I couldn't recalculate the data in a stored procedure that he could do in [image based language] and how he didn't think it was a problem that he didn't store his results thus denying and interface to another system that would cut the customer's check. It almost turned into a real crime scene. That book looks quite cool, might have to pick it up. Thanks for the link.
- otakucode 11y ago
  Never underestimate what sorts of systems are possible to create and force to continue running by current organization management practices. I personally worked on an extremely (and unnecessarily) large system that had no documentation. When I started, and asked for something that at least explained what the different end executables did, I found that no such document existed. When looking at a problem report which said "system X has problem Y", finding out what code was responsible for system X required talking to large numbers of different team members until you could find someone who knew where system X lived. This system survived because no one in management could bear to pull the bandaid on doing significant rewrites and instead preferred to pay much larger amounts spread over longer time periods to continue accumulating technical debt. It basically made it take 6 months to a year before a new hire could be useful, but once someone was familiar with some corner of the system they mostly just stayed there. Keep in mind that most software engineers don't approach their job with passion. Most of the people I worked with didn't even want to touch a computer when they got home. They didn't spend their weekends contributing to open source projects, or keeping up with the latest techniques. They kept their head down and collected their paycheck. That is what the majority of companies actually want, and it's what they get. That system has since (after a billion-dollar-plus contract to create a replacement system) moved to a 'devops' atmosphere. No automated testing or continuous integration, no, that would threaten the large test team. DevOps to them means what I suspect it means at many non-startup places. It means developers developing on the production environment. It means 10x as many problems cropping up, but management is thrilled because problems are fixed in hours instead of weeks. Development no longer consists of understanding anything, or designing anything, it's just an endless series of adrenaline fueled hasty patches while everyone keeps their fingers crossed that the data doesn't get so corrupted that everything grinds to a halt.

kctess5 11y ago

I'm not sure the stats on this one, but it seems to be that something with 1,000,000 loc would have to have decent documentation, or it would be totally unmaintainable and wouldn't grow to that size without dying a horrible death.

protomyth 11y ago
You would think that, but it can grow without understanding by adding code at the edges which expands then starts the cycle over. A code archeologist[1] would see a central island with bridges to developed islands with more bridges and various ships running between interfaces. Its particularly fun with multiple subsystem teams. Each one builds its own island of code and the bridges are scary. 1) please say that exists
- TranquilMarmot 11y ago
  I could probably describe my current job as a "code archaeologist"...
- archgoon 11y ago
  > 1) please say that exists The term 'software archaeology' has been used for a while https://en.wikipedia.org/wiki/Software_archaeology https://en.wikipedia.org/wiki/Software_archaeology And the wiki page suggests there are some consultants in the field. Many programmers trying to understand open source projects will dabble a bit in this.
  - Rusky 11y ago
    Vernor Vinge's novel A Deepness in the Sky has "programmer archaeologists" working on their starship fleets that have thousands of years worth of software going back to "the 0-second of one of Humankind's first operating systems": https://en.wikipedia.org/wiki/A_Deepness_in_the_Sky#Interstellar_culture https://en.wikipedia.org/wiki/A_Deepness_in_the_Sky#Interste...
  - hga 11y ago
    I have been just such a consultant/employee doing this, even started calling it software archaeology some time in the '90s. It's a very painful way of earning money, but there's a whole lot of "poorly documented or undocumented legacy software implementations" out there. Generally effectively undocumented, for many projects start out with some documentation, don't keep it up to date, and by the time you get your hands on the mess it all, including comments, are more a statement of intention at one point in time than something directly and immediately useful.
    - alch- 11y ago
      > It's a very painful way of earning money But.. strangely fun, in a twisted way? I love a blank canvas or a well-written codebase as much as the next guy, but I find that fixing "legacy"[1] codebases can be pretty enjoyable. Slowly figuring out and fixing a "legacy" codebase, to me, is basically solving a giant, complicated puzzle that was left for you by your predecessors. Granted, you're mired in evil gunk from the past, but every time you figure out a small piece of the garbage and refactor it into something nice, you get to feel awesome. Of course, this assumes that you've convinced management that the codebase must be tamed[2] and that this will take time; otherwise you're just fighting with your hands tied. Then again, maybe I'm just a masochist. [1] "Legacy", because people don't like it when you call it "evil gunk from the past that must be destroyed". [2] And it must indeed be tamed, because otherwise it will just grow more and more evil until development grinds to a halt. If management understands this, they'd be crazy to choose the "let the beast grow" option.
      - otakucode 11y ago
- eric_h 11y ago
  I would think that anyone taking on maintenance of a code base that's been under active development for more than 5 years and no longer employs the original developers will necessarily be practicing code archeology.
- bcbrown 11y ago
  I bet you'd enjoy http://www.amazon.com/Your-Code-Crime-Scene-Bottlenecks/dp/1680500384/ http://www.amazon.com/Your-Code-Crime-Scene-Bottlenecks/dp/1...
  - protomyth 11y ago
    The book title made me think of why I still wake up at night from reliving a conversation I had with a developer when I was doing an interface, who was so proud I couldn't recalculate the data in a stored procedure that he could do in [image based language] and how he didn't think it was a problem that he didn't store his results thus denying and interface to another system that would cut the customer's check. It almost turned into a real crime scene. That book looks quite cool, might have to pick it up. Thanks for the link.
otakucode 11y ago
Never underestimate what sorts of systems are possible to create and force to continue running by current organization management practices. I personally worked on an extremely (and unnecessarily) large system that had no documentation. When I started, and asked for something that at least explained what the different end executables did, I found that no such document existed. When looking at a problem report which said "system X has problem Y", finding out what code was responsible for system X required talking to large numbers of different team members until you could find someone who knew where system X lived. This system survived because no one in management could bear to pull the bandaid on doing significant rewrites and instead preferred to pay much larger amounts spread over longer time periods to continue accumulating technical debt. It basically made it take 6 months to a year before a new hire could be useful, but once someone was familiar with some corner of the system they mostly just stayed there. Keep in mind that most software engineers don't approach their job with passion. Most of the people I worked with didn't even want to touch a computer when they got home. They didn't spend their weekends contributing to open source projects, or keeping up with the latest techniques. They kept their head down and collected their paycheck. That is what the majority of companies actually want, and it's what they get. That system has since (after a billion-dollar-plus contract to create a replacement system) moved to a 'devops' atmosphere. No automated testing or continuous integration, no, that would threaten the large test team. DevOps to them means what I suspect it means at many non-startup places. It means developers developing on the production environment. It means 10x as many problems cropping up, but management is thrilled because problems are fixed in hours instead of weeks. Development no longer consists of understanding anything, or designing anything, it's just an endless series of adrenaline fueled hasty patches while everyone keeps their fingers crossed that the data doesn't get so corrupted that everything grinds to a halt.