Refactor before or after ship?

Question

In a world where most ship dates are dictated by business needs, programmers usually ship code that works. Often, structure and efficiency of code being shipped become moot when you know code works. Unless production quality is specified (api to an algorithm for example), for code running into few hundred lines, shippable code equals code that works.

My question is this: Give an ETA for a feature, would you code until feature works and be done? Or would you get it to work as quickly as possible and refactor for release quality?

My inclination is towards the latter though it sounds like more work. When code that works is taken apart for algorithmic efficiency and patterns, it is a joyful experience putting it all together. Besides, it gets all that non-functional love - less bugs, performant, extensible, secure.. I don't think I am good at writing the best code first time. So this approach works well for me.

I'd like to know which one is preferred and why? I am not looking for industry-wide approach, just individual propensities so I can gauge likeness of thought.

Answer 1

For me, refactoring should be done after shipping, ensuring all the functionality works, and left it to the next iteration of code building. If you start manipulating code before shipping you may end up doing little optimisations and finally be left with invalid code.

Answer 2

If you're doing Test Driven Development. Often you write the simplest thing that works first and then refactor as additional functionality is added (AKA Red, Green, Refactor).

There's obviously a big grey area in this question though. If you're shipping an unmaintainable mess then perhaps you should review how you're going about writing code in the first place. Refactoring should be done for some purpose - to make code more flexible to allow a new type of Product for example. Don't just refactor because you feel you should.

Answer 3

I prefer refactoring before and after shipping.

Postponing any refactoring until after release sounds awfully like you're probably never actually going to do it (more often than not, something more business-critical comes up). But even if you do it before shipping, it's not like you're code is perfect and you run out of things to improve. So afterwards too (as long as the code is maintained to any extent).

To me, refactoring code into something simpler and cleaner is continuously and naturally part of any software development work.

Edit: Obviously you need to consider business constrains when deciding how much and for how long you refactor at a given moment.

Edit 2: As for the question "how to convince my manager about refactoring" (see comments), here are some resources that might help:

• Explaining Refactoring to Management at InfoQ
• Martin Fowler's seminal book Refactoring (available online in its entirety, it seems) has a section entitled "What do I tell my manager?". I actually recommend reading the first couple of chapters of the book in any case, as they explain basic ideas about refactoring more clearly than anything else I've seen.

Answer 4

I try to write the best code initially but have always found that once it goes to production refactoring is inevitable. Usually refactoring after code release has been the norm because of user feedback.

Answer 5

In our team, we consider non refactored code as not "done". In other words, "code has been refactored" is part of our Definition of Done, it's one of our criteria for shippable code.

Answer 6

I would prefer to refactor before shipment. You are right, my first code is often not the best design. But if youu have a passing test for the code, there should be little risk to refactor directly afterwards.

And the problem with doing it later is simply "after the release if before the release". In my experience there is no reason to hope there is time to clean up after the release.

Answer 7

Problem is, if you have tendency to only refactor after shipping, you will never do it ;)

I tend to see 'done' including well factored code.

There are exceptions of this rule, if there is a very large scale refactoring which involves high effort. To meet a deadline you could push to next development iteration.