5 ms·

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

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.

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.