Maintaining Legacy Code: Pros, Cons & Analysis

[rigetFrog]

I've been maintaining and updating some legacy code for a while at my job. These Dilberts came up the other day

http://www.dilbert.com/2014-08-11/

http://www.dilbert.com/2014-08-12/

I see people disparage others work/code all the time, and it frustrates me. I give people credit / benefit of the doubt for making the best decision at the time. However, I'm starting to think my acceptance is holding back my career.

Like every engineer, I think it's easier to re-write than to modify, but my bosses priority is to be as efficient as possible with my time, and re-writing has a large over head in time. But some times, I genuinely think the last guy did a pretty good job. I suspect saying so, i.e. "hey, the last guy did a pretty good job with this code" to my boss reflects poorly on me and impede my career.

Here's my concern and pro-con analysis.
_____
Pro's of re writing
allow me to take ownership and credit for it.
makes it easier to debug in the long run.
I get more hands on learning experience
_____
cons of rewriting
Large investment of time
_____
pro of not re-writing
Boss potentially saves time
_____
Cons of not re-writing and just maintaining
My perceived contribution is very little. (Even though modifying code is very hard)
Boss will grieve losing previous employee that did a good job.
_____

What are the PF community's thoughts on this?

 

[StatGuy2000]

There are a number of questions that come to mind which are worth exploring before deciding on whether to maintain legacy code or re-write the code:

(1) Does the legacy code still work well, or well enough for the tasks that it was intended for?

(2) How difficult or time-consuming is it to maintain the legacy code?

(3) Related to (2), how robust is the code? If you need to add further functionality to the code, will the code still run smoothly, or is there a good chance that you'll introduce new bugs?

(4) How well-documented is the existing legacy code? This is worth consideration if for some reason you decide to leave your present position and someone else takes over -- how easily can someone new pick up on the legacy code?

(5) If you decide to re-write the code, how much time will it take to do so? And not just writing the code, but also in preparing the documentation so that someone new can take over it once you are no longer working in the area.

 

[D H]

I'm on the opposite side of you, rigetFrog. I get to write the code that you have to maintain.

I occasionally get phone calls or email messages pertaining to code I wrote over ten years ago. "Your name is at the top of the list of people who wrote this code. Can you explain what this code is doing?" It quickly becomes obvious that I DID NOT WRITE THAT CODE. Yes, all caps, and in bold to boot. After a decade of modifications, my short, simple, well-architected code has become a twisted maze of illogic with functions whose cyclomatic complexity approaches 100. Mark added a special case, then Susie added another, then John tweaked it a bit, and so on.

There are a number of reasons this happens so often:

• My short, simple, well-architected code didn't cover all the cases, was too simple, and it wasn't nearly as well-architected as I thought it was.
• I was myself constrained when I wrote that code. Those constraints may well have disappeared in the intervening decade.
• Maintenance programmers have to solve very specific problems, and they have to do so with rather limited amounts of time/money. If that means adding special case after special case to the code, so be it.
• Maintenance programmers in general are not the cream of the crop. Management assigns fresh outs, has beens, and those they think never will be to maintenance projects.
• That supposed cream of the crop who get to work on those new problems -- we're not near as good as we (or management) think we are.

 

[AlephZero]

Like every engineer, I think it's easier to re-write than to modify, but my bosses priority is to be as efficient as possible with my time, and re-writing has a large over head in time.

I'm an exception to your "every". Through experience I've come to the view that unless you can see a simple way to either reduce the number of lines of code by a factor of 10, or make it run 10 times faster, the best way to have a long and happy life is leave it alone as much as possible.

There's an old Chinese proverb that says "the best way to govern a large country is the same way that you fry a small fish". In other words, don't continually prod and poke it, or it will fall apart before it's cooked. That also applies to large computer systems!

 

[jkl71]

I see people disparage others work/code all the time, and it frustrates me. I give people credit / benefit of the doubt for making the best decision at the time. However, I'm starting to think my acceptance is holding back my career.

I also find that frustrating, however, I’d be dishonest if I said I’ve never done it. Most people I know do it to a certain extent, I personally try to resist doing it. Except in very unusual work environments I don’t think not disparaging other people’s work will hold you back.

I would distinguish disparaging as generalized criticism/complaining from honestly trying to actually be helpful.

One example of how I did this effectively and IMO some other people didn’t. I joined a company, some of the former developers had left some were still there. I spent a couple of days reading the code, found a few problems and scheduled a couple of meetings with the remaining developers to talk about the problems. The criteria for the things I covered were as follows. I only talked about systematic problems, I didn’t see any point in talking about random errors, everybody makes those. I made a rational case why things should be done differently. There were a couple of things that weren’t quite universally accepted as a bad coding practices, in those cases I gave the arguments as best I could for both sides. I tried to convey an attitude of being helpful, that is I was trying help the product and help the devs learn some things. I definitely didn’t want to come off as though I was putting people down or trying to display how awesome I am.

Later two more developers joined the team, one was very good, and the other thought he was, but was pretty mediocre. They both spent a lot of time talking about the code saying: “this is crap”, “this is garbage” and such. Just so I don’t sound defensive, they weren’t talking about my code, but rather the code that existed when I joined. It annoyed the existing dev staff because some of it was their code and the other parts of it were written by their former co-workers (with whom they had good relationships with). It annoyed me because I thought it was gratuitous: it wasn’t done to be helpful, but rather as an excuse to say, “look how smart I am”. Both of these people eventually created multiple severe bugs, in one of the case for each he couldn’t figure out what he did wrong and I had to solve it for him (two of the bugs were catastrophic and 1 of these got into the production environment). I thought at the time “looks you’re not nearly as good as you think you are”.

In summary, when critiquing code I’d suggest focusing on systematic problems, making sure your approach is better and being low-key.

As far as rewriting vs working with the legacy code, I don’t have much to add except to echo the excellent advice of StatGuy2000, D H, and AlephZero. One thing, keep in mind there may be a lot of business rule that have been coded into the legacy application that aren’t documented anywhere. Some of these may obscure, but important and were originally found in the field, this is a risk. It’s not just your time taken up by rewriting. Some of these resources will likely be required: QA, configuration management and deployment. As D H alluded to, you may create a great product, but careless devs can turn anything into a pile of goo pretty quickly. It’s possible you’ll be seen responsible for all the future problems associated with it even if you actually did a pretty good job.

I wouldn’t think this is an issue of not rewriting “My perceived contribution is very little”, if you’re boss knows what he’s doing he’ll appreciate it when you solve problems whether it’s fixing bugs in existing code or writing new code.

 

[tygerdawg]

We all want to think we can do it better. If I re-wrote it, it would be more supportable, have more functionality, be better documented, be more efficient. Blah Blah Blah.

I suppose those arguments have merit in some circumstances. I certainly am guilty of those Dilbert attitudes in my past life.

Older & wiser now, and can appreciate the Boss' point of view. And I no longer SuperGlue my Ego to my work, either. Boss cares little for efficiency, style, elegance...any of that stuff that makes writing code a borderline "artwork" affair. Boss just wants a functioning solution, on time, under budget. Simple.

The most successful, happiest, and least-stressed programmers I've met understood this. They cranked it out, meeting specifications on time, hammered it until it worked, and moved on to the next assignment. Sometimes it was shameful ugly junk code, but it was working shameful ugly junk code. But Boss considered them a talented, resourceful Journeyman programmer who always got the job done. So what is correct in this situation?

Carry on and crank it out as best as one can. There will ALWAYS be someone behind you who will complain/modify/re-write whatever it is that you've done.

 

[Astronuc]

I've been maintaining and updating some legacy code for a while at my job. These Dilberts came up the other day

http://www.dilbert.com/2014-08-11/

http://www.dilbert.com/2014-08-12/

I see people disparage others work/code all the time, and it frustrates me. I give people credit / benefit of the doubt for making the best decision at the time. However, I'm starting to think my acceptance is holding back my career.

Like every engineer, I think it's easier to re-write than to modify, but my bosses priority is to be as efficient as possible with my time, and re-writing has a large over head in time. But some times, I genuinely think the last guy did a pretty good job. I suspect saying so, i.e. "hey, the last guy did a pretty good job with this code" to my boss reflects poorly on me and impede my career.

Here's my concern and pro-con analysis.
_____
Pro's of re writing
allow me to take ownership and credit for it.
makes it easier to debug in the long run.
I get more hands on learning experience
_____
cons of rewriting
Large investment of time
_____
pro of not re-writing
Boss potentially saves time
_____
Cons of not re-writing and just maintaining
My perceived contribution is very little. (Even though modifying code is very hard)
Boss will grieve losing previous employee that did a good job.
_____

What are the PF community's thoughts on this?

Much has already been said based on personal experience. So I'll offer my contribution.

Whether or not legacy code should be preserved depends on a number of factors, including:

Compatibility with modern computational systems

Type(s) of problems to be solved and complexity

Efficiency of the old vs potentially new solution techniques

. . . .

I had the experience of inheriting legacy code in Fortran 77, as part of a project to upgrade the code or replace it. It was programmed in the day when memory was very limited and hardware expensive. It solved a limited class of problems, and was rather coarse spatially and temporally.

When it was decided to implement advanced methods, it was decided to take a more advanced code (but also written in the days of limited memory and expensive hardware), so parts of the old code were lifted and transformed into the new code. That worked OK.

On the other hand, I found a glaring error that had passed through rounds of review and QC/QA, so I was rather amused, but quite a few folks were upset. Obviously there was a rather fundamental oversight on the part of a lot of folks including the developers, reviewer, independent reviewers, and users. Probably the documentation and V&V activities were not as robust as folks believe them to be.

Now I'm looking at modern multi-scale, [coupled] multi-physics computational systems that are being developed to solve similar problems with more detail (finer spatial and temporal resolution). Some of the legacy code has been brought into the current system - and it's not going as well as expected at the beginning of the program.

In addition, we find that the experimental data has been processed into rather coarse (too coarse in some cases) input streams, so important details are not available. That's critical in time-dependent (dynamic) systems in which phenomena have various time dependencies/sensitivities, as compared to steady-state or static systems.I've seen problems with programmers who do not understand the physics behind what they are programming, but they simply write program according to certain principles they learned or understand. Some of the best programming that I've seen has been done by scientists or engineers who have a fundamental understanding of the mathematic and physics of a problem AND know how to program. That seems to be a rare situation these days.