Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

cog (4665)

Journal of cog (4665)

Wednesday July 16, 2008
05:25 PM

Legacy Code :: When it's just not worth it

[ #36936 ]

So there's an already deployed system.

It doesn't take more than a glimpse to notice the following:

  • no versioning control, just the deployed version
  • no documentation
  • no comments
  • commented code
  • a bunch of scripts, one for each step of the algorithm
  • a Perl system, shell scripts that invoke the Perl scripts in specific orders, a PHP backend
  • a bunch of stuff in crond
  • a bunch of files ending in ~, .bak or .old
  • a directory called bk (yes, from backup)
  • a couple of files with different names but with the exact same content
  • an ever increasing number of processes, which sometimes have to be killed when the machine is running too slow
  • a database with tables that have several columns that have never been used
  • several modules, in the same namespace, with replicated code among them
  • several modules with replicated code inside them (copy-paste, yes)
  • way too many lines of code with more than 80 characters
  • to be honest, way too many lines of code with more than 120 characters (the record is 588)
  • lack of indentation
  • lots of spaghetti code
  • a bunch of things you'd never do in Perl
  • nested if clauses where you could use a simple dispatch table (these ones make my eyes hurt)
  • for and foreach mixed around (at least you should pick one and stick with it...), sometimes Perl-style, sometimes C-style (sometimes using $i, sometimes using $xy, sometimes using other variables)
  • hardcoded passwords
  • serious security problems (at least judging by the amount and complexity of SQL queries constructed without using placeholders)
  • a testing directory with nothing resembling tests; just a couple of scripts which you run and then you look at the output to see if it's what you were expecting, assuming you know what the output is supposed to look like, of course
  • and then a directory called "legacy", into which I don't even dare look

And that's just a glimpse.

Normally, I wouldn't write a post about something like this... But seriously, can you see the amount of problems with this thing? And it's only from 2005! And from a guy who keeps writing on his blog about how clever he is!

Now tell me: What would you do?

I'll tell you what the people in charge decided to do... Rebuild the whole thing from scratch. Forget it even exists, and start all over again, this time with someone that (hopefully) knows what he's doing (that would be me).

And now, a personal note...

It's always easier to complain and to criticize other's code than doing it yourself.

I would totally understand that one day, the person who built that system would come across this post or something else I'd written about his project, and would come back at me, in a defense of his technical skills.

With that in mind, I'd like to leave a note to that person, regarding how he built this thing:

I dare you to explain what you were thinking and the decisions you took, assuming you took any!

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • Maybe you really are superior at maintaining a system like that, but FWIW in the systems I've worked on it seems to just be how things eventually end up. I probably just suck too, though. I would like to work in one of these mythical places where development is done sanely.

    For one thing, if he's like me, he probably doesn't have enough resources to able to carefully document and test things. I've heard the arguments before about how these things actually save time over the long run and blahblahblah, so I do

    • You do make a point, but this is a system that consists of only 53 files, counting all scripts, modules, sql files, etc.

      I've dealt with legacy systems that had thousands of modules, that had grown over the years, also with no documentation whatsoever, and it was nothing like this.

      While I agree that the lack of documentation and that kind of thing may not be his fault (but instead a product of circunstances), there are clearly a lot of things that are the product of a non-programmer creating code.

      Again, it m

      • This is me complaining about a specific system and a specific programmer and the discrepancy between his skills and the skills he claims to have.

        Ok, I guess you just hit a nerve with me. ;)

  • I know you didn't inherit my codebase, because I used source control. But the rest of it....
  • I think I've done every one of those at some time in my career, just not all in the same codebase. I probably did a quarter of them just yesterday. :)

    Well, okay, I don't think I've had a 500 character long, but I did have a period where I thought everyone should go back to the 132 character line printer width. That lasted like a month.

    • Yes, but I'm sure you weren't going around bragging how good you were.

  • You can either refactor, or drop it.

    Either way, this is what I would do first:

      1. create a repository for your project;
      2. import the project from the production server into a subdirectory: call it "old", "mess", or "omfg", I don't care;
      3. foreach part of the code that you refactor or drop, remove it from the old directory and commit to a decent organized place.

    At the end of the refactor, your old directory should be empty, but you can always go back in time and see what happened to ea

    life is short