When is it acceptable to rewrite someone else's code?

Question

I largely work as my own dev shop, for a small organization in a large multinational. Almost every day, I find myself rewriting or upgrading my own code to a more informed solution. Obviously, this is fine, since I wrote the code I take no offense at rewriting it. However, I wonder if my reaction would be the same if someone else rewrote my code.

The question is, when is it acceptable or even desireable to rewrite code written by someone else? By this, I do not mean fixing little errors; I mean a total rewrite, possibly something which accomplishes the same thing the original code did in a different (not necessarily better) manner.

On a side note, what are the reactions of people whose code gets overwritten? Is it okay to be a little miffed, or are more intense emotions like anger or humiliation common?

I ask because I do not know.

Answer 1

It's acceptable to do this when:

1. You are responsible for it; and
2. It has a bug in it; or
3. It has a relevant performance problem with it.

Otherwise, leave it alone. Same goes for your code. Code could always be better. It doesn't need to be perfect. In fact, it will never be perfect. What's more, every rewrite potentially introduces new bugs. It is a risk so shouldn't be undertaken lightly.

Perhaps I'm mistaken but reading between the lines of what you're saying, it seems like you take it upon yourself or otherwise go out of your way to change existing code (yours and others). If you are senior to that person or they're on your team or you're otherwise responsible for their work then you have a stake in that code, otherwise you really don't.

And if you are responsible for that person or their work then you should be helping hem understand what's wrong with what they've done and how they can do it better. That's what leadership positions in development teams are all about.

And if you can't make a case for why your version is substantially better (no, slightly better doesn't cut it) then you shouldn't be doing it. There is a tendency amongst programmers to fall into the trap of thinking the way we do things is the right way. You need to avoid that. Thinking you're right doesn't make you special. We all think we're right.

Answer 2

Keep in mind when rewriting someone else's code that they may have a different understanding of the problem than you have. If you find yourself thinking "Why on earth did he do it that way?", you should step back and reconsider rewriting it. Old code has hacks because someone found bugs and fixed them. You should be sure you're not introducing regressions.

Answer 3

I will rewrite code when the time it takes to learn the code will be longer than it would take to write something equivalent that's easier to maintain. You should be able to see that pretty easily

Answer 4

This depends on the context you are working in, and the expectations of your coworkers.

Generally, I'd say the decision to rewrite should not be influenced by who wrote it. If it needs fixing/refactoring, do it.

However, it's both polite and advisable for practical reasons to discuss this with the original author first, if only to learn more about why the code is like it is.

If you do that, a rewrite (if it is really necessary) should be no problem.

Answer 5

Are you afraid of hurting their feelings? Don't be. If you have a solid objective reason for changing the code, then the original developer should be able to recognize it as such when you explain it to them. Remember, most smart developers hate nothing more than their own code from six months ago, so they'll probably agree that a change is needed.

Answer 6

If someone did a rewrite of some of my code without making any improvements (i.e. quicker or more readable), i'd likely be confused/annoyed/pissed. Somewhere within that range.

If they made improvements, I'd be okay with it. After all, the worst code I've seen recently is my own.

Answer 7

The solution to this problem is simple - talk to the person who's code you think needs re-written and come to an agreement on the best way forward.

Answer 8

I think any developer who is worth anything doesn't "like" others rewriting their code. Nothing wrong with that, just means they take pride in their work. In the multi-developer environments that I've worked in I've improved on others' code (including comments to make sure it's clear that I made changes and why). I try to avoid doing so without good cause. I'm always especially careful to make sure I understand what's going on in the code I'm about to alter - as it's typically harder to make bug-free changes to someone else's code than it is your own.

Finally, some mention of version control systems should be made here. Namely, have one in place in multi-developer environments.

Answer 9

I find this to be a somewhat sensitive subject especially given that I am commonly forced to do this at my job. Fortunately for me I am the only .NET developer here so any re-writes are accepted blindly by coworkers, but that's just me.

The best advice I can give is to consider a couple important questions:

1. Do you have to maintain/update this code frequently?
2. If you make changes who will benefit? (You, the customer, other employees)
3. In the long run is making these changes going to take more effort than dealing with the current code?

As the old adage goes: If it ain't broke, don't fix it. There's nothing wrong with upgrading ugly, just try not to step on anyone's toes in the process.

Answer 10

By this, I do not mean fixing little errors; I mean a total rewrite, possibly something which accomplishes the same thing the original code did in a different (not necessarily better) manner.

I don't think it's ever really acceptable to do a full rewrite of code that already works, assuming that code is NOT causing production or maintenance problems. I mean, who has the time? Also, if you're seeking perfection, you'll be at it a long, long time. Writing code is like writing a book--you're never really "done".

That aside, I do make small changes to my team's code when I see design flaws, bugs, or if certain coding conventions have not been followed. Better yet, I point these things out to the responsible parties and let them do the rewrite. Some of these things are shaken out during code reviews, for example.

Answer 11

In an Agile project, the code belongs to the entire team. So it is everyone's responsibility to ensure the code is of the highest quality. This means that anyone can refactor any part of the code base at anytime.

We need to move beyond this idea that code belongs to a single person or is owned by a single person. The code belongs to the business, not to you. As a professional craftsman, it is your responsibility to ensure the quality of the code.

However, I would make a distinction between rewriting and refactoring the code. I am not sure it is ever responsible to rewrite code. Business is not paying you to re-implement something that already works. However, it is everyone's responsibility to refactor the code to make it cleaner and easier to understand. This is simply part of what it means to be a professional software developer.

Answer 12

Just a comment: I agree with sleske, but consider your environment: Doing that within a sprint in your project might upset your boss.

If your change is going to be polemic (code-formatting, tabs versus spaces, line endings and/or encode), make sure to at least come up with a list of reasons, sample affected scenarios likely to be fixed, and side effects.

If you're sure, just notice the developer and push it, but avoid doing that frequently.

BTW: Slight performance hits are not a good reason if preparing for UAT/Testing. Mark that or keep your changes locally, and push while on system test.

Answer 13

I won't talk to the issue of evaluating whether code is good or not. That is up to your criteria.

If you have decided the code is completely terrible: Consider how much interaction you will have with this bad ("sucky") code in the future. If it's a lot, it's sometimes worth rewriting it just to keep yourself sane.

Answer 14

A key point to consider is the fact that by rewriting code you are adding risk to the project. If that code is production code that was not assigned to you to improve, then I would not touch it without discussing it first. If you end up breaking something in a corporate environment for any reason, you might end up pretty sorry you made that change.

Answer 15

After you've done a code review (with the person who wrote it if possible) and you understand the requirements behind the code. If you cant answer the question "Why does the code look the way it does?", then you probably shouldn't change it because you will probably add more problems than you solve (at least that is my experience).

Answer 16

Firstly, it depends on the project scope. If you are fixing code that is being managed by someone other than yourself then you need their buy-in. It is for all intents and purposes their code.

Secondly, it depends on your goal. If you are doing a total rewrite because the code is not maintainable or has obvious bugs then it should be rewritten. However, that does not mean that YOU should be the one to rewrite it. In order to help other team members grow you need to show them their mistakes and let them try again. Pair programming would come in nicely here - otherwise get buy in and sit down with the dev(s) in question and help them.

Finally, it depends on why you think your code will be better. Good code is very subjective and you need to prove that your code will be better. If you are rewriting to take advantage of some new programming features/constructs then you should think again. As per point 2, if there are obvious bugs or maintenance issues then the code should be rewritten...

Just my two cents..

Answer 17

This is a complex question with a lot of variables.

1. How bad is it, really (all codebases seem bad when you first inherit them.).
2. How good can you make it?
3. How long is it going to be around? (it has to be around long enough to get the return back on the rewrite)
4. How likely is it that there are terrible security problems that are difficult or impossible to fix in the current rev (it only takes one massive security hole to sink a project).
5. How bent out of shape will the person who wrote the code get?
6. How much power do they wield in the organization?
7. How responsible are you for the project?
8. How long will you be involved?
9. How many developers are there who are comfortable with the current codebase?
10. Will fixing it require new technologies/frameworks/tools?
11. How flexible is your management in allowing for this type of work?

Bottom line, -is it best for the customer-.

In my younger days, I always wanted to change thing, but I've developed a healthy respect for running, working, production code. There is value in that. Unless there's a clear win, it's a waste to rewrite it. Be objective, stack the pros and cons, and make your case. It's best if you can make the decision collaboratively. If you give the other person chance to have some ownership as well, and don't attack it unnecessarily, they will often be more than happy to admit it's not the best code.

Also, your vision of the right way may differ from theirs.

Think of it like redecorating. If you're visiting a friend for a weekend and staying in their guest room, it would be insane to repaint, change the bedding, and hang new drapes, no matter how much you hated them. It would be a waste of effort, and they'd be insulted and confused. If you were staying for 6 months, you might very well want to have that conversation though. And of course if it's your house you're moving into for 5-6 years, you'd have no qualms about knocking down a few walls or expanding the kitchen, no matter what the previous owner thought.

In the end though, never rewrite the thing wholesale. Do it piecemeal, bit by bit, and move to what you want after dealing with day to day problems for a while. By dealing with the day to day issues with the current codebase you learn about what sorts of things you need to handle, and plan accordingly. Customers -hate- the "sorry, no new features for this release" unless things have gotten so bad that the app is actually unstable and they notice the problems.