[boyter]

You are missing the point. Lots of large applications I work on maintaining have large awful methods. This feature is excellent in these cases.

You could argue that I should re-factor the whole thing to avoid this issue, but certain design decisions made by someone else make this a huge change, and in the world of risk adverse enterprise applications that is not going to happen.

[hkarthik]

Can you not start writing tests against those monster methods so that you've got a refactoring safety net?

I totally agree on being practical and not refactoring methods that work correctly. But if you find yourself in the monster methods making changes quite often, it seems irresponsible to not refactor and leave the camp ground cleaner for the next time you or someone else comes through it.

[boyter]

Its a big ball of dependencies with no chance to mock due to someone deciding on being "clever". Its up there with being untestable.

Generally I agree. If possible clean it up, but quite often its a small one line change, which needs to be fixed ASAP, so there is little chance to refactor.