A recent lunch led to a great conversation about refactoring other developers’ code and when it is reasonable to do so. Generally, I believe it's unwise to refactor other developer's code without talking about it first. Especially when the code you want to refactor is a peer or a lead. We came to a conclusion that it is fair to refactor without comment when you are under a tight deadline and its the only way you can see to fix the problem.

First, I really don't like refactoring someone else's code if that person still works at the company. It can be seen as a vote of no confidence and a real ego bruiser. Even the worst developer still takes pride in his work and making that person upset or angry does not make your project go more smoothly. Discussions, mentoring and positive criticism will often get the point across and the person learns how to write better code.

There are still times when it is reasonable to go ahead and refactor the code without warning. Let's say you are working the weekend to hit a deadline and you have to make sweeping changes to someone else's code and you can't get in touch with him. This scenario happens in somewhat older projects where the old code has been patched over and over again. It was good code once, but the application has grown beyond the algorithm. The best way to fix it is to rewrite it into clean code that fits current requirements.

Hopefully you have a good understanding of what the code is supposed to do and can write one or more replacement methods that adds new functionality while faithfully recreating the old. It is very easy in these situations to regress. At this point, the best thing to do is to test, commit the code and then tell the developer responsible for code about what you did and why. Most people will be gracious and happy that you fixed what was probably seen as a burden. Other developers may get really crabby or even yell about the changes. However, hitting deadlines is often more important than personal egos and real pros are often ready to accept that.

Another scenario is when you are the lead developer and you have several people churning out code for a set of features. Sometimes you have to integrate all that code which often requires some measure of refactoring. You may see, for example, that an algorithm is simply incorrect and will not operate correctly. If you have time, you should bring it to the attention of the responsible developer and communicate the problem. If a deadline is looming then you are probably better off just making the changes and telling the person about it later.

Clearly, there are two common themes here. The first is that communication is critical, whether good or bad. The idea is to drive home why you made changes to explain your point of view and hopefully get buy in. Its also the opportunity to find out whether your change is really appropriate. Sometimes the refactored code is worse because it introduces regressions in other concealed areas. The owning developer is often the only person that knows about these other dependent components.

The second theme is time. The tighter the deadline, the faster you have to move. Missing deadlines can impact sales, support, documentation, QA, salaries and staffing. This may sound a little over the top, but many customers only budget and buy during certain times of the year. Missing a customer's budgetary or buying cycle can mean missing an entire year's worth of revenue from that customer. Small companies with few customers are very sensitive to losing revenue. Consequently, slipping a date because you didn't want to modify someone else's code is usually not helpful.

Communicate and delegate when there is time and refactor carefully when there isn't.