|Perl: the Markov chain saw|
Re^2: "Practices and Principles" to death (do change)by tye (Cardinal)
|on Mar 01, 2008 at 06:31 UTC||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:
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.)