in reply to The Boy Scout Rule

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.

Replies are listed 'Best First'.
Re^2: The Boy Scout Rule
by eyepopslikeamosquito (Bishop) on Jan 26, 2015 at 20:04 UTC

    The text you quoted does not appear in the node you replied to.

    Why do you repeatedly reply to the wrong post? Or is this another PerlMonks site "bug"?

Re^2: The Boy Scout Rule
by BrowserUk (Pope) on Jan 27, 2015 at 01:02 UTC


    Not because I disagree with you; but because of your inane, facile, puerile, snide, underhand and utterly deliberate practice of posting a reply to a particular node; as a response to {some other} randomly chosen node.

    What the .... do you think it achieves? (Paraphrase:Why are you such a deliberate, willful moron?)

    With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority". I'm with torvalds on this
    In the absence of evidence, opinion is indistinguishable from prejudice. Agile (and TDD) debunked
      It achieves the goal of making you expend energy against the troll, while they sit back and admire their handiwork :)
      The post is more visible because after a given response depth they are hidden. Being everywhere is the best you can do to sell your work when the content of those posts should close every door.