Sunday, November 12, 2006

Is a refactoring project navel gazing?

If your project is refactoring code without adding new features, is that time well spent?

How do you tell when you're finished?

How do you tell if you were successful, or even if you utterly failed?

How do you decide what needs refactoring?

How do you know that what you are refactoring will make things easier in the future?

Are past successes indications of future performance? In other words, will your future projects have the same problems that your earlier ones did?

What happens if you choose the wrong piece of code to refactor?

Don't spend money refactoring code until you know that you will see a benefit from the refactor. You've got better things to do with your time - like inventing new products. Otherwise, you've got a high likelihood of refactoring dead code.

Technical and Architectural Debt are terms used by software engineers as an excuse to rewrite code they don't like. Don't fall for it.

6 comments:

Bwooce said...

I'd never heard of those two debt terms. I'll have to use them :-)

Exploring this further, (based on memories of TQM from Deming:

If you have no goal then you won't get anywhere useful except as a happy accident.

If you have no way of measuring progress towards your goal then you are only going to get there by accident.

If you have neither you have increased the likelyhood that there will be no happy accident.

Happy accidents are uncommon.

Camping Fag said...

"In other words, will your future projects have the same problems that your earlier ones did?"

Bwahahahahaha. Worked here long, have you?

Jason Pollock said...

Camper, you're a smart-ass. :)

How many of those re-occuring problems would be solved by refactoring the code?

Very, very few. :)

Determinist said...

Refactor or redesign? That's the real question.

You are arguing that if it doesn't need a redesign, it doesn't need a re-factor?

I can see your point.

I do think that refactoring does have its place, and that's usually when the code is so bad that you feel sick to your stomach just looking at it.

Of course, done poorly, code refactoring just makes it hard to find the real changes that are happening. I was merging one of your fixes to a new branch and you'd done a re-factor. There were something like 100 lines of change and 3 lines of fix. That was a case of refactoring done incorrectly.

If you are going to do a refactor, it should be done as a separate project, separate from fixes. That way, fix transactions show up as distinct from the re-factor. Also, use a decent refactoring book as a standard, otherwise everyone re-factoring will end up making it look however they want it to, and the reason you refactored is still around (i.e. multiple people writing code in their own way)

Jason Pollock said...

I must admit, I had to read that a couple of times. :) Took me a minute to figure out who you were determinist, but I guess the name should have given it away. :)

In defense of my poor, little refactor, if I hadn't done the refactor, I wouldn't have been able to fix the bug. Three different variables to describe a single state!

I'm not talking about small, local refactors. I'm talking about, "Hey, let's throw 4 developers, 3 testers and a project manager in a room for 3 months and refactor a bunch of code!".

I'm essentially arguing, why have a project who's goal is redesign? If your sole goal is to redesign the product, it's pure navel gazing.

However, if you've got a feature to add (or bug to fix) that requires the redesign, congratulations you've cleared the bar!

Take the current project, how many faults have we had to fix in that area of code in the past year. I count 5. How many CR's in that code? 2?

It's stable code, let it rot slowly and go write new stuff.

Determinist said...

You say: "Hey, let's throw 4 developers, 3 testers and a project manager in a room for 3 months and refactor a bunch of code!"

I have never seen that happen - ever, at any company I've worked for.

I agree, it's a dumb idea. However, getting one developer to review and possibly refactor isn't a bad idea.

There is too much of "throw this crap over the wall and let support handle it" - you end up with crap code written too quickly.

If you want to write solid code that has fewer bugs, it's not rocket science. Slow down and take the time to do it right. There are lots of good books on the subject.

I once met a magician on a bus when we were both out Christmas shopping. He was shuffling cards with one hand, doing all kinds of cool tricks. I didn't bother asking him how he did it, but he answered the question anyway. He said, "If you go down to the library, there are five or six really good books with all these tricks described. But no matter how many people I tell, they never go to the library, and they remain amazed at my tricks."

Writing code - same thing.