The Old Joel on Software Forum: Part 3 (of 5)

Refracturing

This is a spinoff from the thread 'Am I unique hybrid?' which turned into a discussion about maintenance.

From those who are doing refactoring as part of their normal routine, there were gasps of horror at those who weren't.

I work in a place where releases are heavily regulated, and any changes to the code need full user authorization, user testing on dev completion plus signoff from management. I don't have full control over my environment here. Speaking as someone who isn't doing refactoring - except when I've got some code out for An Approved Reason - it doesn't seem to easy to bring the concept in.

I'm sure I can't the only one in this bind. How would you happy refactorers change such a maintenance situation?

Shodan
Wednesday, December 10, 2003

Dang dude I feel for you.

Given that they've got a lock down on stealth refactoring (sheesh!) and criminal penalties for rogue refactorers you can either:

1. tell them to change the environment, using whatever you can from xp or whatever books you can find (don't mention xp to them, just use the books to get hard data on refactoring. mention xp and it will become a methodology war)

2. find a different place to work

3. Become resigned to your unfulfilling job

I have a feeling that 1 won't work. Assuming 3 is bad for you, try 2. If 1 doesn't work and you can't do 2 for whatever reason 3 is what you're left with.

if they didn't have the 'System' you describe, I'd add #4, stealth refactoring, ie ignore the asses and do it anyway.

Tony Chang, the Happy Refactorer
Wednesday, December 10, 2003

Tony, Number 2 is pretty high on my list at the moment (see "Life and Career" thread). I'm not sure how I would broach 1.

I *am* in a fortunate position, I'm seen as someone who is changing things for the better. Still the bureaucracy is climbing higher and higher and I won't be able to turn on my PC without authorization soon.

Just looking for ideas... although I'm still trying to introduce the concept of a spec (or something along those lines).

Shodan
Wednesday, December 10, 2003

I expect the reason for your lockdowns is to prevent unapproved *functional* changes, and *untested* changes.

Thus, the only way you're going to get to do refactoring is if you can institute automated testing, and they agree to making it the *test suite* that's locked down for approved changes. Then, you can have your refactoring cake, and the users can eat it too.

Phillip J. Eby
Wednesday, December 10, 2003

Agreed, it doesn't seem unreasonable to have a certain level of lock down on production code. Refactoring does add risk, especially if you don't test for functional changes. If things are working fine in production it's rare that you'll find a manager who wants to change it just to clean up code. You're going to have to have some good reasons why the refactored code is better than the original.

chris
Wednesday, December 10, 2003

You're allowed to change the code if you have an Approved Reason (e.g. a bug to fix or a new feature to write).

That's fine: if you need to fix a bug (or add a new feature), then refactor as much as necessary/desirable as part of your effort.

On the other hand, for any code that's working fine as is (no bug to fix, no new feature to write), you don't even need to read it, let alone refactor it.

Wednesday, December 10, 2003

My feeling was, yes, it comes down to testing. The app base I deal with (there are a lot of independent apps) had been around for a few years before I showed up. None of them have any automated testing. For my new apps, I apply automated testing, but I'm still working amongst people who don't recognise the value of building tests (as opposed to just "doing" them).

Shodan
Wednesday, December 10, 2003