Biz & IT —

What are the unwritten rules of deleting code?

A total rewrite is no laughing matter.

What are the unwritten rules of deleting code?
Stack Exchange
This Q&A is part of a weekly series of posts highlighting common questions encountered by technophiles and answered by users at Stack Exchange, a free, community-powered network of 90+ Q&A sites.

sglahn Asks:

We are practicing collective code ownership. To my understanding this means that any developer can change any line of code to add functionality, to refactor, fix bugs, or improve designs.

But what about a complete rewriting of code from a developer who is still on the team? Should I ask him first? What is the best practice?

Related: "When is a BIG rewrite the answer?"

Talk it out

Matthew Flynn Answers (47 votes):

I think good communication is always the best practice. Talk to the developer and see if there's a reason why it's coded the way it is. It may be that they have been meaning to get back and refactor it for ages, it may be that they did it that way for a very good reason, or it may be that you both can learn something from the conversation.

Going in and rewriting without prior communication is a recipe for ill will.

What's wrong with your workflow?

Aaronaught Answers (13 votes):

The very premise of this question raises a number of concerns for me that I don't think any of the existing answers are adequately trying to address. Let me ask some follow-up questions here:

  1. Are you absolutely, positively certain that you are talking about rewriting and not refactoring? By definition, changes to code style or structure that result in an improved (or simply different) implementation without changes to the external behavior is a refactor, not a rewrite. Breaking a monolithic 500-line routine into a set of 50 subroutines may involve writing quite a bit of new code, but it is not a rewrite. The term rewrite implies throwing away an entire product or feature and starting over from scratch; it is not something to be taken lightly.
  2. If the original code's behavior is so wrong, or the implementation is so buggy as to require a full-fledged rewrite, why was it not caught by your team's process and addressed in its proper context (i.e. technically rather than socially)? Bad or questionable code ought to be exposed quickly on a healthy team via tests, code reviews, design reviews, etc. Do you have these?
  3. Is the manager/tech lead aware of the problem, and if not, why not? No matter what kind of process you have, code quality is ordinarily the development manager's responsibility. He or she is the first person you should be asking—obviously not in the context of "so and so wrote crap code" but simply "I think I see a major problem here, can we talk about a rewrite?" If it doesn't warrant this type of discussion, then maybe it doesn't warrant a rewrite either?
  4. If the size and scope of the offending code is large enough to warrant serious discussion of a rewrite, why is it exclusively owned by one developer? Most if not all of the times when I've seen code and thought "rewrite", it's been trampled on by a dozen different people and the badness is a direct result of the accumulation of style inconsistencies, mistaken or altered assumptions, and good old-fashioned hacks. Code grows thorns over time precisely because of its shared ownership.My point here is, it's strange that one person would own such a large swath of code in an environment that supposedly practices collective ownership. Are other people afraid to touch this developer's code? Are they afraid to bring up the subject? Maybe there is in an underlying problem with your group dynamic, or with this developer specifically; if there is, don't ignore it. Or, alternatively, perhaps it is your first time working on this project, and if so, why are you thinking about a rewrite so early in the game? Something about the situation doesn't seem to add up for me.
  5. The question states, in the first paragraph: "any developer can change any line of code to add functionality, to refactor, fix bugs or improve designs." Will a rewrite not do these things? Or will it do something extra—and if so, what? Fundamentally, what are your reasons for wanting to do a rewrite, and how sure are you that they'll benefit the product or the team? You don't need to answer for me, but you'd better have some objective points to make if and when you choose to discuss it with the team.

I truly feel that this question entails a huge amount of context and should not be answered without a very clear understanding of that context. The "correct" answer completely depends on your team, your product, your organization, your personality, your process, the scope of the original code, the scope of the changes, and so on and so forth. This is, IMO, an issue that you absolutely need to take up with your team, not on an online Q&A site.

Related: "How do you explain refactoring to a non-technical person?"

Find the original post here. See more Q&A like this at Programmers, a site for conceptual programming questions at Stack Exchange. And of course, feel free to ask your own.

Channel Ars Technica