The open close principle and refactoring

[Cogman]

What is your opinion on both? Mine has generally been "If something stinks clean it up" however my team mates are more of the opinion "If it isn't broke don't touch it."

I can see the value in strict adherence to the Open closed principle, but it seems like it is more of an excuse to let rotten code live long past its usefulness.

 

[degibson]

Usually for me something demonstrably incorrect trumps a problem that just smells wrong. I guess if I ever ran out of work, I might refactor based only on smell, but that hasn't happened yet.

 

[LumbergTech]

I think there is value in revisiting and doing things better to make your staff better at what they do, but you do have to balance it with what absolutely must be done vs what would be nice to do.

 

[Leros]

It comes down to the return on investment. What return do you get on the investment of cleaning up the code? If nobody is going to touch it again, then you get no return and cleaning it up was a waste of time. If it's code that a lot of people are working in, then cleaning it up will increase productivity and reduce bugs, so you do get your return on investment.

 

[Train]

I think you are using the term "Open closed principle" incorrectly.

http://en.wikipedia.org/wiki/Open/closed_principle

 

[beginner99]

Usually for me something demonstrably incorrect trumps a problem that just smells wrong. I guess if I ever ran out of work, I might refactor based only on smell, but that hasn't happened yet.

That's probably the main issue here. As long as there are real and known bugs, they should have priority. And I would say you will almost always be in this situation.

Refactoring can easily have a huge, unexpected "tail". At least for me refactoring means changing the design. So I guess if you are not 200% sure you know all the effects it will have (which is probably only the case in you personal open source projects), I would not do it unless explicitly told do so.

 

[KB]

I understand why your teammates would be of the opinion that "If it isn't broke don't touch it." If you "fix" the ugly code and you end up introducing huge bugs (possible even with near 100% test code coverage) you are likely to get fired. They are just keeping their head down.

For me, those "ugly fixes" can be done in major version releases, but not in minor releases. People expect possible changes in behaviour in major releases, but not minor releases.

 

[exdeath]

Leave it alone unless there is tangible benefit.

 

[BrightCandle]

This is not what the open/closed principle means, at all. Open Closed is part of the Solid principles.