My take on opportunistic refactoring is different from the interpretation I read here.   Rather than: I've got some time on my hands so lets go looking for something to change; I interpret it to mean: I am in this piece of code anyway -- due to a bug to fix or functionality to add or change -- and if I see something else that here that can be (demonstrably) improved whilst I'm here, and then make a case for doing so.

Hear, hear!

My point-of-view is admittedly altered by being the consultant who is called-in to (re-)evaluate present state and to (re-)plan future state on projects which are presently “on fire,” or, as the case may be, “smoking [ruins].”   One of the things that the client asks is ... “can we simply get back to the stable-state where we used to be, and proceed forward (older but wiser) fom there?”   In order to give a meaningful answer to the question, I look at [look for ...] the change-order log and the associated [try somehow to associate it with ...] the git or svn commit and branch history.

What I find, way-y-y-y too often, is that there really is no correspondence between the two.   “A single commit” does not correspond to “the remedy to that service-order, no more and no less.”   Far too often, the developer found something that smelled bad [to him ...] and “simply fixed it,” and didn’t tell anyone.   Didn’t structure the change so that it could be backed-out.   And didn’t update the validation test-suite (which should have detected any regression), because there wasn’t one.   The (now mostly-departed) team gave only lip-service to testing because it took time away from the secret Ruby re-write making Kewel New Fee-Churs.   In any case, no management was guarding the hen-house.   Management simply decided that the programmers were un-manageable anyway trusted the programmers to know what they were doing, and did not realize that those programmers were flying a 747 by the seat of their pants ... were making it up as they went along ... didn’t know what they were doing, either.

Testing, to me, is simply one of several expressions of discipline.   Way, way too many programmers out there have no discipline at all.   They were taught “how to write source-code,” not how to build robust, maintainable, software machines that must safely carry passengers without a pilot or co-pilot on board.   To their training and experience, “source code” is “the end,” not “the means to a different end.”

And, if you asked me where the “fabled disconnect” comes, between programmers and management, that would be my reply.   To a classic software developer, everything is software.