All the Perl that's Practical to Extract and Report

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

cog on 2008-07-16T22:25:52

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!

not necessarily his fault

slanning on 2008-07-17T09:09:18

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 don't need a lecture. But if you don't have enough people to deal with all the business demands and bug fixing, at some point you start to be the one who is getting in the way, and then it's you who are the idiot who needs to be removed. And no matter how well you try to document what you do, if there are other people working on things and they don't document what they do, and people come and go in your company, and have diverse skills and motivations, then that tacit knowledge erodes over time.

And users don't ever know what they want. So you make any system, regardless of how elegant and clean it is, you end up making little compromises to accomodate this or that thing that popped into somebody's head and is suddenly a very important thing to have. Or otherwise, if you try to keep your precious system immaculate, you're just getting in the way and need to be removed in order to get things done. Or if your system is sufficiently decayed, you look stupid because something that should be ridiculously easy to change is not unless you add yet another dirty hack. [bah, I'll stop here arbitrarily]

Re:not necessarily his fault

cog on 2008-07-17T09:23:57

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 may not be his fault, but given how the guy goes around in conferences and the internet exalting his development skills, I am really pissed.

And this is not something that has grown over time, AFAIK, it's just a not very large system that was very poorly designed and implemented.

Again, you do make a point, but this system is nothing like that.

This is not me going after everybody who's done bad coding in the past (heck, I'm probably in that group also).

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.

Re:not necessarily his fault

slanning on 2008-07-17T11:01:11

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

*whew*

jtrammell on 2008-07-17T12:11:17

I know you didn't inherit my codebase, because I used source control. But the rest of it....

Guilty

brian_d_foy on 2008-07-18T03:27:54

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.

Re:Guilty

cog on 2008-07-18T08:56:16

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

Path foward

melo on 2008-07-25T10:45:21

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 each piece of the old system.

Regards,