Premature Refactoring?

Question

We have all heard of Premature Optimization, but what do you thing about Premature Refactoring? Is there any such thing in your opinion? Here is what I am getting at.

First off, reading Martin Fowler's seminal work "Refactoring" quite literally changed my life in regards to programing.

One thing that I have noticed, however, is that if I start refactoring a class or framework too quickly, I sometimes find myself coded into a corner so-to-speak. Now, I suspect that the issue is not really refactoring per se, but maybe premature/poor design decisions/assumptions.

What are your thoughts, insights and/or opinions on this issue? Do you have any advice or common anti-patterns related to this issue?

EDIT:

From reading your answers and reflecting on this issue more, I think I have come to the realization that my problem in this case is really an issue of "Premature Design" and not necessarily "Premature Refactoring". I have been guilty of assuming a design and refactoring in that direction to early in the coding process. A little patience on my part to maintain a level of design agnosticism and focus on refactoring towards clean code would keep me from heading down these design rabbit trails.

Answer 1

I think any "1.0" project is susceptible to this kind of ... let's call it "iterative design". If you don't have a clear spec before you start designing you're objects, you'll likely think of many designs and approaches to problems.

So, I think overcoming this specific problem is to clearly design things before you start writing code.

Answer 2

I actually think the opposite.

The earlier you start thinking about whether or not your design needs refactoring, the better. Refactor constantly, so it's never a large issue.

I've also found that the more I refactor early on, the better I've gotten about writing code more cleanly up front. I tend to create fewer large methods, and have fewer problems.

However, if you find yourself "refactoring" yourself into a corner, I'd expect that is more a matter of lack of initial design or lack of planning for the scope of use of a class. Try writing out how you want to use the class or framework before you start writing the code - it may help you avoid that issue. This is also I think one advantage to test driven design - it helps you force yourself to look at using your object before it's written.

Remember, refactoring technically should NEVER lock you into a corner - it's about reworking the internals without changing how a class is used. If your trapping yourself by refactoring, it means your initial design was flawed.

Chances are you'll find that, over time, this issue gets better and better. Your class and framework design will probably end up more flexible.

Answer 3

There are a couple of promising solutions to this type of problem, depending on the situation.

If the problem is that you decide something can be optimized in a certain way and you extract a method or something and realize that because of that decision, you are forced to code everything else in a convoluted way, the problem is probably that you didn't think far enough in the design process. If there had been a well written and planned spec, you would have known about this problem ahead of time (unless you didn't read the spec, but that's another issue :) )

Depending on the situation, rapid prototyping can also address this problem, since you'll have a better idea of these implementation details when you start working on the real thing.

Answer 4

I think it is possible to refactor too early.

At the nuts and bolts end of design is the code itself. This final stage of the design comes in to existance as you code, it will at times be flawed and you'll see that as the code evolves. If you refactor too early it makes it harder to change the flawed design.

For example its much easier to delete a single long function when you realise its rubbish or going in the wrong direction than it is to delete a nice well formed function and the functions it uses and the functions they use etc, whilst ensuring you're not breaking something else that was part of the refactor.

It could be said that perhaps you should have spent more time designing but a key element in an agile process is that coding is part of the design process and in most cases, having put some reasonable effort into design, its better to just get on with it.

Edit In response to comments:-

Design isn't done until you've written code. We can't solve all problems in pre-coding design, the whole point behind Agile is that coding is problem solving. If the non-code design solved all problems up-front before coding there would be no need to re factor, we would simply convert the design to well factored code in one step.

Anyone remember the late 80s early 90s structured design methods, the ones where you got all the problems solved in clever diagrams before you wrote a line of code?

Answer 5

I am a strong believer in constant refactoring. There is no reason to wait until some specific time to start refactoring.

Anytime you see something that should be done better, Refactor.

Just keep this in my mind. I know a developer (a pure genius) who refactors so much (he is so smart he can always find a better way) he never finishes a project.

Answer 6

The reason why premature optimization is bad is that optimization usually leads to a worse design. Unlike refactoring, which leads to a better and cleaner design, if done thoughtful and right. What I learned to be useful for me to analyze the usefulness of a refactoring was first looking at our UML diagram to visualize the change and then writing the code-doc (e.g Javadoc) for the class first and adding stubs ahead of any real code. Of course experience help a lot with that, if in doubt, ask your favorite architect ;)

Answer 7

We have all heard of Premature Optimization, but what do you thing about Premature Refactoring? Is there any such thing in your opinion?

Yes, there is. Refactoring is a way of paying down technical debt that has accrued over the life of your development process. However, the mere accrual of technical debt is not necessarily a bad thing.

To see why, imagine that you are writing tax-return analysis software for the IRS. Suddenly, new regulations are introduced at the last minute which break several of your original assumptions. Although you designed well, your domain model has fundamentally shifted from under your feet in at least one important place. It's April 14th, and the project must go live tomorrow, come hell or high water. What do you do?

• If you implement a nuts-and-bolts solution at the cost of some moderate technical debt, your system will become more rigid and less able to withstand another round of these changes. But the site can go live and proceed onward, and there will be no risk of delivering late; you're confident you can make the required changes.
• On the other hand, if you take the time to refactor the solution so that it now supports the new design in more sophisticated and flexible way, you'll have no trouble adapting to future changes. But you run the risk of your company's flagship product running up against the clock; you're not sure if the redesign will take longer than today.

In this case, the first option is the better choice. Assuming you have little previous technical debt, it's worth it to take your lumps now and pay it down later. This is, of course, a business decision, and not a design one.

Answer 8

Premature refactoring is refactoring without unit-tests. You are at that point simply not ready for a refactoring. First get some unit-tests and then start thinking about refactoring. Otherwise you will (might) hurt the project more than help.