2 ms·

> 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

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

by alch- 11y ago

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