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

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 your 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 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.