4 ms·

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 unmaint

by 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
        It certainly has its moments. Hell, just looking through the legacy code and seeing what other people did can be entertaining in a 'holy shit would you look at that!' way. I will never forget when I was working on a codebase in which the author apparently did not know how to loop or how to hold user interface controls in an array or something. There were 10 textboxes on the screen. Instead of looping through the textboxes and calling a stored procedure with the content of each one (it was PL/SQL inside an Oracle Form... a dead structure never meant to be used to create a full application which is what they'd done with it), they first handled the case where textbox 1 had content, but the others did not, with one procedure call. In the else, it handled the situation that textboxes 1 and 2 has content but the others did not with 2 procedure calls.... and on and on and on for all 10 textboxes. Pages and pages of nearly identical code. I would have expected any self-respecting programmer to either have said 'there HAS to be a better way' and stubbornly search for such a way, refusing to proceed along the terrible path I saw before me, or else leave the profession entirely. But someone somewhere went through and constructed the whole repugnant edifice...
- 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.

by kctess5 11y ago

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
      It certainly has its moments. Hell, just looking through the legacy code and seeing what other people did can be entertaining in a 'holy shit would you look at that!' way. I will never forget when I was working on a codebase in which the author apparently did not know how to loop or how to hold user interface controls in an array or something. There were 10 textboxes on the screen. Instead of looping through the textboxes and calling a stored procedure with the content of each one (it was PL/SQL inside an Oracle Form... a dead structure never meant to be used to create a full application which is what they'd done with it), they first handled the case where textbox 1 had content, but the others did not, with one procedure call. In the else, it handled the situation that textboxes 1 and 2 has content but the others did not with 2 procedure calls.... and on and on and on for all 10 textboxes. Pages and pages of nearly identical code. I would have expected any self-respecting programmer to either have said 'there HAS to be a better way' and stubbornly search for such a way, refusing to proceed along the terrible path I saw before me, or else leave the profession entirely. But someone somewhere went through and constructed the whole repugnant edifice...
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.