4 ms·

> 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.o

> 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...

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...