Beefy Boxes and Bandwidth Generously Provided by pair Networks
Just another Perl shrine

Comment on

( #3333=superdoc: print w/replies, xml ) Need Help??

The thing I have found is that Herkums tend towards extremes. They believe that those who rarely test believe themselves infallible. And they believe that those who test extensively believe that testing can prevent any problem. :)

I don't think I've ever met anyone who thought their coding was infallible (certainly not for very long) nor that thought that their testing was infallible.

Most of the coders I've met who did little testing (all coders test) had some awareness of some of the potential benefit for a more rigorous approach to testing. They never allocated the time to make enough progress on creating and adopting that more rigorous approach yet.

Most of the coders I've met who did a lot of testing were very much aware of the fact that their testing was imperfect. They would, when practical, spend some of their time budget trying to improve the efficacy of their testing (certainly not always by increasing the number of tests) and reducing the costs of testing. With a limited time budget (which I find is the rule, even when it isn't imposed upon you by your boss), there are always trade-offs to be balanced.

The horror stories in these threads don't sound to me like a problem with programmers believing too much in testing. They sound to me like organizations having developed too much / too rigid of a bureaucracy.

I have been lucky to have only worked for very brief periods of time in companies that were so large and so old that they had huge, rigid bureaucracies. This is in part because I don't apply for jobs at such companies and also because I don't stay very long at jobs in such companies after the small company that I was working for was purchased by the huge, old company.

My brief stays have shown me that appealing for change to the bureaucracy is daunting and very nearly pointlessly doomed. The rigid, structured hierarchy of rules is augmented by a rigid, structured hierarchy of employees with rigid, structured vested interests. The only hope (nearly) is to fish out some nuggets of worth (either code or people) and transplant them into different location(s) lacking the accumulated encrustment. (This is true even when this is attempted within the umbrella of that company.)

And I also don't think that the most significant problem is that people don't "think". Certainly that is a fairly common problem, though, to a small extent for most people and to a larger extent for many people.

The more significant problem (in my opinion, with regard to the problem scenarios touched on in these threads) is that most people don't believe that they can influence the existing power structure so they don't try (and a few people just go about it very badly and so their attempts fail).

People buried under excessive testing requirements certainly do "think". Day in and day out they think "why do I have to do all of this nonsense?". They even identify particular parts of their job that seem the most pointless, that produce the least "bang for the buck". That is a very valuable piece of information to identify. Too bad they (mostly) never do anything useful with that information.

This is very much like the people who show up at PerlMonks (both "regulars" and first-time callers) asking questions that sound like "is there a type of hammer that works better for hammering in dry-wall screws?". Eventually the denizens coax some explanation which is that "the boss/client heard that nails are inferior and won't let us use them / refuses to buy a power screwdriver" and therefore "there is nothing I can do" and "that was no help. thanks, anyway. i have to go pound all of these screws in now. bye."

That is professional negligence.

If you see something stupid / pointless being required, then it is your responsibility to effectively communicate this observation to the powers that be (if you feel any responsibility toward the success of the enterprise). And "effectively communicate" can be the rub. If the existing power structure is not annoyingly disfunctional, then usually one or both of the following things will result:

  • The powers learn from your eloquent explanation and the problematic policy / decision is improved
  • You learn things you didn't know and that make you realize that things aren't as stupid and pointless as you thought

Both of those results are good things that are likely beneficial to the enterprise.

And if the existing power structure is annoyingly disfunctional, then you now have a new observation that it is your responsibility to effectively communicate. I've already admitted that there are lost causes here where my advice would be "Get out!". But most organizations aren't lost causes and all organizations are imperfect and most participants will see places for improvements (sometimes erroneously).

So I guess my view is that most organizational stupidity is due to a lack of effective communication not due to a lack of thinking.

In volunteer organizations, this "effective communication" very often has a lot more to do with creating than with talking. Yammering away about some "better way" is very often significantly less effective in a volunteer organization than spending more of your time implementing a better way. Yammering away about "the current way sucks", is usually even less effective (though it can be a starting point, of course -- though starting at just that is usually insufficient of a starting point, despite how common it is).

So I think that better questions than "How do we get people to think?" are "How do we get our workers to believe that they can influence the powers that be?" and "How do we help workers communicate their observations and ideas effectively?".

And for most of you reading this, the question should be "Why don't I try to communicate effectively with the powers that be?" or perhaps "more often" or "more effectively", depending. Learning how to do that will do you a world of good and will likely do a world of good for those around you.

(Updated for spelling thanks to ysth's prodding.)

- tye        

In reply to Re^2: "Practices and Principles" to death (do change) by tye
in thread "Practices and Principles" to death by ack

Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post; it's "PerlMonks-approved HTML":

  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.
  • Log In?

    What's my password?
    Create A New User
    [Corion]: The fun show at $work continues, as The Big Project is now in its second week of frantic live-bugfixing and weekend releases where nobody knows what went live. Nothing has been tested anyway.
    erix mutters cantankerously under his breath
    Corion watches from the sidelines. Or rather, from behind, as my system only gets output from that process and my programs adhere strictly to the GIGO design principle.
    [erix]: ah, that's nice to hear Corion :)
    [Corion]: erix: Yeah, the sad thing is that all I can do is document things, so I can point fingers when the auditors come :-/
    [Corion]: "I'm here to open tickets and point fingers. And I'm all out of tickets."
    [erix]: didn't Sybase have pretty good auditing? :) (this is a vague memory)
    [erix]: (culprits often are upstream of db of course)
    [Corion]: Ah, how I missed it. After some years, I revisit slashdot on a click-bait link, and it provides the usual humor instantly: "I didn't know Drupal had rules for sex. It must be a plug-in"
    [Corion]: erix: This is not for sybase, but for the input data files, resp. their contents.

    How do I use this? | Other CB clients
    Other Users?
    Others scrutinizing the Monastery: (8)
    As of 2017-03-28 08:59 GMT
    Find Nodes?
      Voting Booth?
      Should Pluto Get Its Planethood Back?

      Results (328 votes). Check out past polls.