If you've discovered something amazing about Perl that you just need to share with everyone,
this is the right place.
This section is also used for non-question discussions about Perl, and for any discussions that are not specifically programming related. For example, if you want to share or discuss opinions on hacker culture, the job market, or Perl 6 development, this is the place. (Note, however, that discussions about the PerlMonks web site belong in PerlMonks Discussion.)
Meditations is sometimes used as a sounding-board — a place to post initial drafts of perl tutorials, code modules, book reviews, articles, quizzes, etc. — so that the author can benefit from the collective insight of the monks before publishing the finished item to its proper place (be it Tutorials, Cool Uses for Perl, Reviews, or whatever). If you do this, it is generally considered appropriate to prefix your node title with "RFC:" (for "request for comments").
Governance is the strategic task of setting the organization's goals, direction, limitations and accountability frameworks.
Management is the allocation of resources and overseeing the day-to-day operations of the organization.
One way to think about this is that Governance determines the "What?" - what the organization does and what it should become in the future. Management determines the "How?" - how the organization will reach those goals and aspirations.
Management consists of controlling a group or a set of entities to accomplish a goal.
Leadership refers to an individual's ability to influence, motivate, and enable others to contribute toward organizational success.
Influence and inspiration separate leaders from managers, not power and control.
Though you need all three, my feeling is that Leadership is the most elusive and the most vital ... which might explain
why CEOs are paid so much.
Perl Governance
I'm deeply embarrassed to admit that I learnt just the other day that Perl Governance
is the responsibility of The Perl Foundation (TPF),
a non-profit based in Holland Michigan
(this picturesque and charming city also happens to be the sacred birthplace of Perl Monks! ...
making it an outpost of both Dutch and Perl culture and tradition in the American mid-west :).
Create a vision of the Perl ecosystem in years to come
the goal being to provide information on which TPF, community groups, and individuals
can make informed decisions and plans for the future
(the recent Gobby survey and Ann Barcomb survey (aka kudra) formed part of this early research).
Though this appears to be a misquote ...
repeated 128,000 times (128,001 now ;) ...
the point behind this dodgy Drucker quote can be found in this longer less dodgy one:
What these business needs require are changes in behavior.
But “changing culture” is not going to produce them.
Culture — no matter how defined — is singularly persistent.
Nearly 50 years ago, Japan and Germany suffered the worst defeats in recorded history, with their values,
their institutions and their culture discredited.
But today’s Japan and today’s Germany are unmistakably Japanese and German in culture, no matter how different this or that behavior.
In fact, changing behavior works only if it can be based on the existing “culture.”
In the full article, Drucker derided cultural change as a management fad,
urging companies to focus instead on changing behaviors in order to achieve their desired results.
Stronger, he contended that
changing behavior works only if based on the existing culture -
presumably because culture is intrinsically "sticky" and resistant to change.
Wait, doesn't this contradict the earlier quote exhorting you never to attempt to change company culture?
Oh well, I guess I just don't have what it takes to be a multi-millionaire management consultant. :)
Focusing on behavior, rather than culture, leads us inevitably to
Codes of Conduct.
Codes of Conduct
A code of conduct is a set of rules outlining the norms, rules, and responsibilities or proper practices of an individual party or an organization.
A code of conduct can be an important part in establishing an inclusive culture, but it is not a comprehensive solution on its own.
An ethical culture is created by the organization's leaders who manifest their ethics in their attitudes and behavior.
Studies of codes of conduct in the private sector show that their effective implementation must be part of a learning process
that requires training, consistent enforcement, and continuous measurement/improvement.
Simply requiring members to read the code is not enough to ensure that they understand it and will remember its contents.
The proof of effectiveness is when employees/members feel comfortable enough to voice concerns and believe that the organization
will respond with appropriate action.
Enron was the company that espoused those wonderful core values and made these compelling statements in its 64-page code of ethics booklet -
and we now know how “ethically” many of their employees behaved.
The Enron scandal taught us that implementing an effective Organizational Code of Conduct ain't easy,
requiring strong Leadership, exemplary role models, and significant investments
in training, consistent enforcement, and continuous measurement and improvement.
Curiously, the earliest Open Source Code of Conduct proposal
I could find originated with a Perl programmer! --
one Coraline Ada Ehmke,
"who began writing software in 1994 using the Perl programming language" ... though it seems she's defected to Ruby nowadays.
(Update: I'm reliably informed she even has an old Perl Monks account! ... wouldn't it be great if she replied to this node? ;)
As you can see from the many references listed below, Codes of Conduct seem to have become routine nowadays
in Open Source communities, and in the broader community too.
Cognitive trust: based on the confidence you feel in another person's accomplishments, skills and reliability. This is trust from the head.
Affective trust: arises from feelings of emotional closeness, empathy or friendship. This is trust from the heart.
Cognitive trust is easily and commonly built in Open Source communities,
such as P5P, simply by consistently producing lots of high quality patches.
On Perl Monks too, it's easily built by consistently producing high quality answers.
Though affective trust seems harder to build in the Open Source world,
it's a great way to improve teamwork (and mental health) --
as described at Conflict in Teams.
BTW, the trust hormone Oxytocin is associated with affective trust -- and
also implicated in Dog-human emotional bonding.
So I feel that seeking out effective ways
to build trust (of both kinds) in the Perl community is worth a shot ...
and that effective, inspirational Leadership and role models will help enormously in this endeavour.
What do you think?
I'd like to end this meditation with a heartfelt plea from one of my favourite monks, the inimitable Discipulus
(with whom I've built affective trust :):
At the end we need a new ethic. No one, at every level of contributions, must feel harassed or damaged anymore, please, no one.
We have a lovable language; are we able to build a lovable community?
I have a strong suspect that a Code of Conduct is not enough at all.
A new ethic of collaboration must be defined.
The little power we have must be dissected, redistributed and organized sanely and it cannot only be the origin of judgements and bans.
"I prefer to use pure Perl core modules instead of depending on the CPAN."
Saying that on IRC usually causes a flurry of negative comments. I agree that the CPAN is resource intense, and I've put stuff there. If you use lots of code from the CPAN, I'm not going to make fun of you. However, I would ask that you give me the same respect. Here's why I choose this path.
1. Compatibility Pure Perl modules are portable, the target node doesn't need a set of compiler tools. While XS based modules might improve performance, not all nodes have compiler tools. Some nodes are precluded from having compilers based on resources or security mandates. Depending on a module that may not be installable creates a production risk.
2. Idempotence Well engineered software can be installed and removed cleanly. When I worked for a telco, we would install, remove, and then reinstall software during QA. If it failed at any of those, it failed. Period. There is no "cpan" command to uninstall a module. The "cpanm" -U option for "uninstall" is marked "EXPERIMENTAL". The few times I've tried to use it to install modules that were installed via "cpan", it could not find the modules. Even when I told the command where the module was. If a module cannot be installed and removed cleanly then it does not belong on a production system.
3. Upgradeability The "cpan" -u option (upgrade) comes with the warning: "Blindly doing this can really break things, so keep a backup." This conflicts with the concept of keeping software current to reduce security vulnerabilities and bugs. If a system's software cannot be cleanly upgraded it should not be in production.
4. Security-- See Addendum below -- One of Perl's common object oriented modules is Moose. Installing Moose adds roughly 900 modules to the node. Who is security checking all those dependencies? Who wants to explain each and every one of those modules to a security auditor? In truth, how many of us could explain the risks and benefits of all nine hundred dependencies? And are we being paid to check someone else's code or are we paid to keep a production system running?
5. Immiscibility Most Linux distributions require some version of Perl for operation. This sounds good for Perl, until you realize that the versions are often very out of date. If you want to use a semi-recent Perl you usually have to compile your own and install it somewhere. You also have to install any CPAN modules separately, which means your backups are now taking longer and you have more to sift through when trying to make space. And, of course, anyone who wants to use your code has to concoct the same environment.
Solution
My personal solution is to use pure Perl core modules or pure Perl CPAN modules that do not have a large dependency list. Large, in this sense, is "Am I willing to deal with these dependencies manually?" At some point in time I hope to be Perl-smart enough to help improve CPAN, but I'm not there yet.
Addendum
An earlier version of this page referenced YAML::Tiny in the security section. Investigating, based on hippo's comment (below) about "suggested_options" ('suggests_policy' in MyConfig.pm) removed YAML::Tiny as a culprit. YAML::Tiny has no non-core module dependencies.
This refers to the hardness of finding cliques in a graph when the number of nodes becomes high. My use case is that I am trying to form cliques within a cluster where the sum of relationships is maximum.
Background & definition (anthropomorphized for ease of understanding):
Cluster: A number of persons where each person is related to at least one another person. The strength of the relationship is a number, i.e. Si-j is the strength of the relationship between person i & person j (Symmetric: Si-j = Sj-i). All combinations need not be present - if person x & person y have no relationship then Sx-y does not exist. No relationship with self - Si-i does not exist as well.
Problem: Given a list of relationships Si-j: i from 1 to N, for each i some j from 1 to N, i!= j; (graph with the edges giving the strength of the relationship). Find those groups (cliques) where each member is connected to each other and the sum of the relationship is maximum, e.g. if the persons are as follows:
Person-1 Person-2 Relationship-strength
A B 92
A C 7
B C 2
C D 88
Then the groups formed would be (A,B) & (C,D) for a sum of relationships of 180 (92 + 88).
Any other combination would have a lesser sum, e.g. (A,B,C) & (D) would have a sum of relationships of 101 (92 + 7 + 2).
How I did it: Convert the list of Si-j's into an integer linear programming problem and call a free solver lp_solve. Got good results - out of about 40,000 problem sets (clusters) only about 20 timed out. This on an ancient 3'rd gen i7 laptop with 4GB RAM. About another 10 were "very" large (more than 2,000 edges). Gives me confidence that use of a commercial solver and a larger timeout period may give even better results.
Linear programming problem formulation left out here as it is more an algorithm issue rather than a Perl issue. We can discuss if interested. Off forum perhaps?
Hope this is interesting. And, perchance, if it is useful for anyone then it would be the icing on the cake!
Struggling to make heads or tails (sorry, CARs and CDRs) of Perl culture,
I decided to focus on Perl's creator, Larry Wall.
As indicated by the quotes above - and Larry Wall wikiquotes -
humour is a huge part of Perl culture.
Especially compared to the PhD-powered functional programming community -
for those doubting this stark cultural difference, see the "Black Perl" and "Haskerl" sections
at The Lighter Side of Perl Culture (Part VI): April Fools. :)
Seeking further insights into Perl culture, I began reading Larry's Culture of Perl
keynote from The Perl Conference of '97.
I really struggled to relate to it though, couldn't make heads or tails of it.
Later in the day I suddenly remembered my fluky lunch date with Larry from years ago.
The strong impression I felt that day
was Larry's extraordinary intelligence combined with a delightful kindness and gentleness.
Combining those feelings with Larry's final metaphor from The Culture of Perl:
the theological metaphor I want to leave you with is simply that it is better to give than to receive
and this quote from the Perl Culture chapter of Programming Perl:
the only personality trait Perl programmers have in common is that they're all pathologically helpful
leads to my two primary characteristics of Perl culture:
generosity and helpfulness
quirky sense of humour
As you might expect from my posting history, I never could embrace
TMTOWTDI,
much preferring TIMTOWTDIBSCINABTE (pronounced Tim Toady Bicarbonate).
What are your top two or three attributes of Perl culture?
Intuitively, I've been strongly drawn Util::H2O, and I finally have a solid example that has informed me explicitly what I have been feeling implicitly. My goal is to be laconic this time.
Recently, I was writing a commandline tool in Perl, one of my favorite things to do. I needed Getopt::Long. I also was being nagged internally to use Util::H2O. Why? I simply wanted "real" accessors for the options hashref that I really like using with GetOptions. I ended up with something like this:
use strict;
use warnings;
use Getopt::Long qw/GetOptions/;
use Util::H2O qw/h2o/; # <~ here
my $opts = {};
GetOptions(
$opts,
qw/
option1=s
option2=i
option3
option4!
option5+
/
);
h2o $opts; # <~ here
#...
exit;
__END__
## now we get the following, but only for the options actually passed
+(updated)
# $opts->option1
# $opts->option2
# $opts->option3
# $opts->option4
# $opts->option5
Almost magically, with the addition of a single line (well, 2 if you count the use Util::H2O qw/h2o/; line,) I had accessors for $opts. I was pleased, to say the least. Note, I have not tried this with callbacks, but I also don't use them much. I suspect that works just fine. (update) Also note, in this case one gets accessors only for the options passed (or more precisely for only the keys that exist in $opts). I suspect this could be leveraged for more interesting and perlish ways of checking what options were actually passed.
And now I can start to quantify where and when I'd like to use Util::H2O - not as an actual way to have a bunch of boiler plate at the top of my script to declare classes (which it does support), but perlishly (and iteratively) adding accessors to hash references - which my code tends to be absolutely full of. I've used it in some other places to clean up existing code and in new code, knowing full well I am going to be slinging hash references all over the place.
In summary - check out Util::H2O. If you're like me, then you'll find little benefits to you that POOP offers can actually be satisfied in this natural way. It also occurs to me, this topic would be an ideal entry for the Perl Advent Calendar - so maybe I'll work out some more examples and make a submission later this year.
After I get a distribution very stable, I go back and try to make it better, faster or more efficient. In IPC::Shareable, I've been benchmarking various serialization techniques to see which one works the fastest. I knew that Sereal was quite a bit faster than Storable, but there are some gotchas with it that I couldn't work around. This morning I tested with JSON, and to my surprise, it blew both out of the water!
use warnings;
use strict;
use Benchmark qw(:all) ;
use JSON qw(-convert_blessed_universally);
use Sereal qw(encode_sereal decode_sereal looks_like_sereal);
use Storable qw(freeze thaw);
if (@ARGV < 1){
print "\n Need test count argument...\n\n";
exit;
}
timethese($ARGV[0],
{
sereal => \&serial,
store => \&storable,
json => \&json,
},
);
cmpthese($ARGV[0],
{
sereal => \&serial,
store => \&storable,
json => \&json,
},
);
sub _data {
my %h = (
a => 1,
b => 2,
c => [qw(1 2 3)],
d => {z => 26, y => 25},
);
return \%h;
}
sub json {
my $data = _data();
my $json = encode_json $data;
my $perl = decode_json $json;
}
sub serial {
my $data = _data();
my $enc = encode_sereal($data);
my $dec = decode_sereal($enc);
}
sub storable {
my $data = _data();
my $ice = freeze($data);
my $water = thaw($ice);
}
I have bodies of code to maintain and improve. Using tests is a given, and TDD is a wonderful thing. I am still learning Perl culture, and would appreciate guidance on tools and processes.
My parameters are hopefully simple. I prefer clear and verbose code so I can understand it the next time I read it. When producing tools I prefer to stay as close to Core/StdLib Perl as possible. When working *with* tools, more options are open. For example, using a Perl::Critic plug-in while developing code is fine, shipping those add-ons is something I would avoid.
My current plan is a cycle of:
Write Tests
Kwalitee
Perl::Tidy
Perl::Critic
Repeating as necessary, or until I have to ship the code. Are there other tools to add to the mix? Better processes?
As soon as the button was pressed to mute NASA from our meeting,
the managers said "we have to make a management decision", said Boisjoly.
The general manager of Thiokol turned to his three senior managers and asked what they wanted to do.
Two agreed to go to a launch decision, one refused.
So he (the general manager) turns to him and said "take off your engineering hat and put on your management hat" --
and that’s exactly what happened, said Boisjoly.
He changed his hat and changed his vote, just thirty minutes after he was the one to give the recommendation not to launch.
I didn’t agree with one single statement made on the recommendations given by the managers.
The teleconference resumed and NASA heard that Thiokol had changed their mind and gave a recommendation to launch.
NASA did not ask why.
I went home, opened the door and didn’t say a word to my wife, added Boisjoly.
She asked me what was wrong and I told her
"oh nothing hunny, it was a great day, we just had a meeting to go launch tomorrow
and kill the astronauts, but outside of that it was a great day".
Although changes were made by NASA after the Challenger accident, many commentators have argued that the changes in its management structure
and organizational culture were neither deep nor long-lasting.
After the Space Shuttle Columbia disaster in 2003, attention once again focused on the attitude of NASA management towards safety issues.
The Columbia Accident Investigation Board (CAIB) concluded that NASA had failed to learn many of the lessons of Challenger.
In particular, the agency had not set up a truly independent office for safety oversight; the CAIB decided that in this area,
"NASA's response to the Rogers Commission did not meet the Commission's intent".
The CAIB believed that "the causes of the institutional failure responsible for Challenger have not been fixed",
saying that the same "flawed decision making process" that had resulted in the Challenger accident was responsible
for Columbia's destruction seventeen years later.
Incredibly, NASA, with so many talented people,
had somehow (twice!) failed to remedy a glaring Conflict of interest
organizational structure/culture problem.
It seems they failed to find a way to ensure that the technical team making launch safety decisions were
allowed to do so without pressure or coercion from outside interests.
(Which BTW reminds me of the poor old Release Manager in commercial software companies
being relentlessly pressured by senior management to ship the next release ... less common perhaps in the open source world,
though release management remains stressful).
Perhaps the root cause of NASA's Space Shuttle woes was an unhealthy mix of commercial/financial and engineering/scientific culture.
Certainly, NASA have achieved many breathtakingly brilliant successes in the purely engineering/scientific domain,
such as the venerable Hubble Space Telescope
and the recent stunning New Horizons mission
to Pluto and beyond.
It will be interesting to see in the coming decade if
Elon Musk
or Jeff Bezos
or Sir Richard Branson
can create a more effective culture for commercial space flight.
National Cultures
Social psychologist and former IBM researcher Geert Hofstede identified
five dimensions of culture in his studies of national work related values:
Power Distance. How accepting are people of unequal power distribution?
Individualism. Is individual achievement or collective achievement emphasized?
Masculinity. How much does the culture accept gender roles?
Uncertainty Avoidance. How anxious are folks about uncertainty and risk?
Long-term Orientation. Do people take a long-term view of their work?
Hofstede found that these five dimensions varied considerably
between countries. The United States, for example, rated highest on Individualism,
while Russia and India rated highest on Power Distance.
Japan scored the highest on the Masculinity index.
Russia and Japan have high Uncertainty Avoidance, while Denmark has a low score.
Japan, South Korea and India have a much stronger Long-term Orientation
than Canada, the UK and the USA.
The captain made the decision to land despite the junior officer's disagreements, eventually bringing the plane down short of the runway,
highlighting how a pilot can contribute to a disaster.
In high power distance cultures, it is uncommon for subordinates to question their superiors.
High power distance can be seen as the willingness to be in an unequal position,
making it a challenge for an officer lower in the hierarchy to question the decisions of the one in power.
Korean Air had many fatal accidents between 1970 and 1999, during which time it wrote off 16 aircraft in serious incidents and accidents
with the loss of 700 lives. The last fatal accident, Korean Air Cargo Flight 8509 in December 1999 led to a review of how Korean cultural
attitudes had contributed to its poor crash history. Since then safety has improved.
In the cases of Korean Air flight 801 and Air Florida flight 90 one clear statement could have saved more than 300 lives.
In each case, a series of leadership errors led to the deaths of hundreds of passengers.
Cultural and contextual factors contributed to the leaders unknowingly creating unsafe conditions.
A lack of cultural awareness and understanding of the environment was a culprit in both case studies, along with dozens of other airplane crashes.
These two case studies serve as warnings for all leaders on the importance of including cultural dimensions in their leader(ship)
development programs as well as adapting programs to the specific environmental factors.
By taking a lesson from the aviation industry, other organizations can prevent similar mistakes,
create better leaders and leader(ship) development programs, and possibly save lives.
As a result of this and other accidents, Korean Air’s new CEO set about an ambitious organizational change.
He made English the official language of the airline, redefined roles in the cockpit, and provided extensive communications training,
among other initiatives to change the culture (Wee, 2013).
Other airlines also made changes in response to the reoccurring communication challenges.
One notable change made by many airlines was to adopt a program known as cockpit resource management (CRM).
CRM requires the entire crew to work together and communicate (D’Amato, 2013).
Training programs provide specific skills and procedures to maximize communication and effectiveness.
CRM has proven to be very effective in reducing airplane crashes due to communication, regardless of cultural backgrounds.
Googling Organizational Culture revealed many folks offering
(often pricey) Organizational Culture workshops
based on theories concocted by a pair of enterprising boffins,
quietly contemplating
at the University of Michigan,
located in the picturesque village of Ann Arbor.
Though the definitive reference on their work is available for purchase from amazon, you can also get a feel for their process by reading this early paper:
Abstract: This chapter outlines a process for diagnosing and changing organizational culture.
It uses the Competing Values Framework to describe a validated approach to helping an organization change
from a current culture to a desired culture.
... and from the (mostly youtube) links in the References section below.
As you might expect, I was too cheap to pay for advice on this topic, so instead watched some youtube videos and read Kim's original paper.
Though not necessarily the best organizational change process (alternative citations welcome), at least this
is a concrete thing that can be discussed and analysed, and thus serve as a starting point for
discussing specific ways to improve Organizational Culture (and Perl organizational culture too).
Although many definitions of culture have been proposed, the two main disciplines are:
Sociological (organizations have cultures). Assumes you can identify differences among organizational cultures, can change cultures, and can empirically measure cultures.
Anthropological (organizations are cultures). Assumes that nothing exists in organizations except culture, and one encounters culture anytime one rubs up against any organizational phenomena.
In her 2008 paper, Cameron gave a popular and practical definition of culture as:
the taken-for-granted values, underlying assumptions, expectations,
and definitions present which characterize organizations and their members
which:
serves as the social glue binding an organization together; and
represents how things are around here, affects the way members think, feel, and behave.
and further perceptively noticed that:
With very few exceptions, virtually every leading firm has developed a distinctive culture that is clearly identifiable by its key stakeholders
This distinctive culture is sometimes created by the initial founder: Walt Disney, Bill Gates, and Larry Wall, for example.
All three of these legends developed something special, something more vital than corporate strategy, market presence, or technical advantages:
the power that arises from a unique and spirited culture.
Curiously, most people are unaware of culture until suddenly confronted with a different one:
travelling to Vietnam, for example, finding yourself immersed in different noises and smells and unable to understand a word of the local lingo ... or asking a question on SO after years of posting at Perl Monks. :)
The culture of most organizations is invisible, most members have a hard time describing it, let alone consciously changing it --
that is why you need tools, such as The Competing Values Framework and the Organizational Culture Assessment Instrument (OCAI),
developed by scholars Cameron and Quinn.
Notice that Organizational Climate is distinct from Organizational Culture:
Climate is temporary, Culture enduring.
The Competing Values Framework
This framework, used to assess the dominant characteristics of organizations, differentiates on two vertical dimensions:
Stability, Order, Control (effective if: stable, predictable, mechanistic, e.g. Universities, Government agencies, Boeing)
and two horizontal dimensions:
Internal orientation, Integration, Unity (harmonious internal characteristics, e.g. IBM, the IBM way)
External orientation, Differentiation, Rivalry (effective if: competing with others outside their boundary, e.g. Toyota, Honda)
Together these two dimensions form four quadrants:
Clan culture (Collaborate)
Adhocracy culture (Create)
Hierarchy culture (Control)
Market culture (Compete)
Hierarchy Culture:
Formalised and structured workplace. Procedures and controls govern what people do. Leaders: coordinators, organizers, monitors.
Maintaining a smoothly running organization is important.
Long term: stability, predictability, efficiency, formal rules and policies hold the organization together.
Success is defined in clear lines: authority, control, accountability, e.g. McDonalds, Govt agency on airport controls (strict guidelines for every small detail).
Market Culture:
Competing environment, results-oriented workplace, external environment is hostile, consumers are selective, want value.
Leaders are hard-driving producers; competitors are tough and demanding.
Productivity, results and profits; glue is emphasis on winning.
Success is market share and penetration, e.g. Ikea, Walmart.
Clan Culture:
Friendly workplace, people share a lot of themselves, leaders are mentors, facilitators, team builders, parent figures, held together by loyalty and tradition.
Commitment is high, long-term benefit of individual development, high cohesion and morale important.
Success is defined as internal climate and concern for people, premium on teamwork, participation and consensus, e.g. small family-owned companies, doctors without borders, wikipedia.
Adhocracy Culture:
Dynamic, entrepreneurial culture, people take risks, leaders: visionary, innovative, risk-oriented.
Glue: Commitment to experimentation and innovation, to be at the leading edge, readiness for change is essential.
Long term emphasis is rapid growth.
Success is creating unique & original products and services, e.g. start-ups.
Relationship between the four quadrants:
Each side represents opposites
Flexibility vs Stability
Internal vs External
Competing on the Diagonal: Clan (internal focus) v Market (external focus); Adhocracy (external organic) v Hierarchy (internal control)
The competing on opposite sides of each quadrant give rise to the name of the model.
Why Change Organizational Culture?
The Competing Values Framework Introduction youtube (around the 12:15 mark)
gives a fascinating case study of how Organizational Cultures change over time.
Steve Jobs, a charismatic entrepreneurial leader, was a great cultural fit for
the (Startup culture) Apple of the 1970s ... only to get fired in 1985 for
his chaotic management style, when Apple needed more controls and standard procedures ...
then finally re-hired in 1997 to heroically resurrect the company after it started
having a hard time inventing new products!
That is, Apple culture evolved
from Adhocracy (Apple II era) to Adhocracy/Clan (Macintosh era) to Hierarchy (John Scully era)
to Hierarchy/Market then balanced Hierarchy/Market/Adhocracy/Clan (on Jobs return).
How does a language win? By being compelling enough to be used for new things.
It's not solely a technical concern; it's a concern of the language community and ecosystem.
As indicated in the essay cited above, a good reason for Perl to change its culture may be to
make it more attractive for new projects (compared to competing languages).
Update: see this response for a present-day example of a domain in which Perl is less compelling than Python.
Of course, if Perl was a commercial enterprise, one business strategy to cope with losing market share
may be to seek a merger with Python
... thus allowing our new customers to write some truly astonishing code:
# copy stdin to stdout, except for lines starting with #
while left_angle_right_angle:
if dollar_underscore[0] =eq= "#":
continue_next;
}
print dollar_underscore;
}
Note that if you choose not to attempt to explicitly change your organization's culture, it will change anyway. Culture is evolving all the time.
The Seven Steps To Culture Change
Clarifying meaning.
Identifying stories.
Determining strategic initiatives.
Identifying small wins.
Crafting metrics, measures, and milestones.
Communication and symbols.
Leadership development.
The Organizational Culture Assessment Instrument (OCAI)
It might be fun to create a Perl Monks poll to see how people rate P5P culture or Perl Monks culture.
1. DOMINANT CHARACTERISTICS
The organization is:
A. a very special place. It is like an extended family. People seem to share a lot of themselves.
B. a very dynamic and entrepreneurial place. People are willing to stick their necks out and take risks.
C. very production oriented. A major concern is with getting the job done. People are very competitive and achievement oriented.
D. a very formalized and structured place. Bureaucratic procedures generally govern what people do.
2. ORGANIZATIONAL LEADERS
The leaders of the organization are generally considered to be:
A. mentors, facilitators, or parent figures.
B. entrepreneurs, innovators, or risk takers.
C. hard-drivers, producers, or competitors.
D. coordinators, organizers, or efficiency experts.
3. MANAGEMENT OF EMPLOYEES
The management style in the organization is characterized by:
A. teamwork, consensus and participation.
B. individual risk-taking, innovation, flexibility, and uniqueness.
C. hard-driving competitiveness, goal directedness, and achievement.
D. careful monitoring of performance, longevity in position, and predictability.
4. ORGANIZATION GLUE
The glue that holds the organization together is:
A. loyalty and mutual trust. Commitment to this organization runs high.
B. orientation toward innovation and development. There is an emphasis on being on the cutting edge.
C. the emphasis on production and goal accomplishment. Marketplace aggressiveness is a common theme.
D. formal rules and policies. Maintaining a smooth running organization is important.
5. STRATEGIC EMPHASES
The organization emphasizes:
A. human development. High trust, openness and participation persist.
B. acquiring new resources and meeting new challenges. Trying new things and prospecting for new opportunities are valued.
C. competitive actions and achievement. Measurement targets and objectives are dominant.
D. permanence and stability. Efficient, smooth operations are important.
6. CRITERIA OF SUCCESS
The organization defines success on the basis of:
A. development of human resources, teamwork, and concern for people.
B. having the most unique or the newest products. It is a product leader and innovator.
C. market penetration and market share. Competitive market leadership is key.
D. efficiency. Dependable delivery, smooth scheduling, and low cost production are critical.
Blood Lust, Trust and Blame - new book by sociologist Samantha Crompvoets, reportedly paid more than six million dollars to bring about cultural change in the ADF
because it made me realise that organizational cultural problems are dauntingly difficult -
and often prohibitively expensive - to put right.
For therapy, I've decided to follow up my
nine-part series on Agile processes in organizations
with a new (ten-part :-) series of articles exploring the perplexing multi-disciplinary topic of
Organizational Culture.
There's certainly no shortage of material, with a mind-boggling number and variety of disciplines in play, such as:
Please feel free to mention other disciplines I've overlooked or that you'd like to see discussed.
A possible breakdown by topic is:
Broad Overview of Organizational Culture
Meta Process: that is, a process to build a process to effectively change Organizational Culture
Culture variation in different countries
Software Industry Culture
Open Source Software Culture
Perl Culture
Perl Monks Culture! :)
Space/Aircraft Industry Culture. As a space nut, I doubt I'll be able to restrain myself from scrutinizing the
impact of organizational culture on the Space Shuttle Challenger
and Columbia disasters.
Again, feel free to suggest other topics you'd like to see discussed.
Please note that I'm just an interested layman on all these topics, so please correct me when I veer off course.
I also welcome your feedback and opinion, along with insights, anecdotes and any useful citations you may know of.
To kick off this series, given that I've just finished reading Sapiens, I thought it'd be fun to speculate on how our early evolutionary history
helps explain some of the peculiar and counter-productive behaviour we witness today.
PreHistory
Around 2.5 million years ago, an unremarkable new species appeared in Africa.
Now, I doubt these early humans, enduring their daily battle for survival along with many other species,
had any inkling back then that they would one day walk on the moon, split the atom, map the genome,
calculate the age of the universe ...
and compose Perl programs, obfus and poetry.
How on earth did this unremarkable and physically weak new species win this brutal evolutionary war?
Sapiens
revealed the (surprising to me) secret:
A green monkey can yell to its comrades, "Careful! A lion!".
But a modern human can tell her friends that this morning, near the bend in the river,
she saw a lion tracking a herd of bison.
She can then describe the exact location, including the different paths leading to the area.
With this information, the members of her band can put their heads together
and discuss whether they should approach the river, chase away the lion, and hunt the bison.
Homo sapiens is primarily a social animal.
Social cooperation is our key for survival and reproduction.
It is not enough for individual men and women to know the whereabouts of lion and bison.
It's much more important for them to know who in their band hates whom, who is sleeping with whom,
who is honest, and who is a cheat.
... The most important information that needed to be conveyed was about humans, not lions and bison.
Our language evolved as a way of gossiping.
Do you think that history professors chat about the reasons for the First World War when they meet for lunch,
or that nuclear physicists spend their coffee breaks at scientific conferences talking about quarks?
Sometimes. But more often, they gossip about the professor who caught her husband cheating,
or the quarrel between the head of the department and the dean, or the rumours that a colleague
used his research funds to buy a Lexus.
Only Homo sapiens can speak about things that don't really exist.
You could never convince a monkey to give you a banana by promising
him limitless bananas after death in monkey heaven.
But why is it so important?
Fiction has enabled us not merely to imagine things, but to do so collectively.
We can weave common myths.
Such myths give Sapiens the unprecedented ability to cooperate flexibly in large numbers.
Ants and bees can also work together in huge numbers, but they do so in a very rigid manner and only with close relatives.
Sapiens can cooperate in extremely flexible ways with countless numbers of strangers.
That's why Sapiens rule the world, whereas ants eat our leftovers and chimps are locked up in zoos.
(Update: so far researchers have failed to locate lawyer bees; bees don't need lawyers because there
is no danger that they might forget or violate the hive constitution).
Myths and fictions accustomed people, nearly from the moment of birth,
to think in certain ways, to behave in accordance with certain standards,
to want certain things, and to observe certain rules.
They thereby created artificial instincts that enabled millions of strangers to cooperate effectively.
This network of artificial instincts is called culture.
The theory of evolution tells us that instincts, drives and emotions
evolve in the sole interest of survival and reproduction
... yet when some of these evolutionary pressures abruptly disappear (due to sudden changes in human culture),
these hard-won instincts
do not instantly disappear with them ...
which explains why today young men drive recklessly and fight in pubs.
They are simply following ancient genetic impulses that, though counter productive today,
made perfect sense 70,000 years ago, where a
young hunter who risked his life chasing a mammoth outshone all his competitors
to win the affections of the local beauty.
Sadly, those same successful macho genes today give us a mouthful on Perl mailing lists, IRC and Twitter.
With their brain growing (to keep track of the thousands of connections, deceits and subterfuge required for superior gossiping)
and their hips narrowing (to facilitate walking upright), evolution favoured early births
... leading to helpless babies ... requiring a tribe to raise them ... favouring those with strong social abilities.
Being born immature and with a big brain further allowed humans to be taught more flexibly than any other species --
which explains why we witness today the appalling spectacle of impressionable youngsters being
effortlessly led to love Python and hate Perl.
Updated: Make Homo sapiens stand out from surrounding text, and with the species name (sapiens) in all lower case, a convention used by biologists, such as erix. 13-June: added bee lawyer joke to quoted Sapiens passage.
I'm old-school, object-oriented programming didn't start to get mainstream until I'd been in the industry 20 years (the roots go back to before my start, of course). And then Perl has a not completely generic approach to objects.
Today I learned, less painfully than I might have, that when I instantiate an object in one program, use Dumper to make it a string, send that to another program, and eval the string, I get an object exactly matching what Dumper saw (I know there are cases where it can't do that, but my situation is simple and that part works). But...the blessed object and the class/package it's associated with don't interlock. So, having forgotten to include that package in the second program, evaling the Dumper string gave me a blessed object (hash, in this case) with all the right members -- but didn't notice that the package was missing, and that therefore all the methods, including accessors, were missing.
Oops!
I didn't take that long to realize what was wrong, even. It's a cleavage line I don't think exists in most other object environments.
No particular point beyond this; I'm not saying this is bad and must be fixed or anything. It's an extra way to screw up (which I exploited :-) ) made possible by the flexibility of Perl's rather ad-hoc approach to objects. "Meditation" is about right; I'm just thinking about this out loud.
I suppose you could make this a slightly harder mistake, but only by making some low-level changes. If a blessed object kept track of whether it was associated with a package of that name, and the information went into the Dumper output, then when the string was evaled, if there was no package of the right name loaded, it could point that out (optional extra parameter to bless, or something?). Huh; my first thought was that it was going to be hopeless, but maybe there are holes in that idea I haven't noticed yet. I wonder if there is code out there that deliberately uses this somehow?
I often have to update Perl and the CPAN dists i use for my projects on many machines at once. Over time i have to come more and more to realize how much of a drag badly written test suits are. In this post, i'll try to formulate this into a somewhat readable list of things that can be improved.
Make your tests as short and fast as possible
Some dists really seems to drag their feet when it comes to running tests. Do you really need to run a gazillion slow tests on every single computer your dist is installed? This wastes the users time.
For example, do you really need to test if 1+1=2? You can assume that Perl did some extensive tests on the basics during its installation, so you don't have to.
Don't run extensive "timeout" tests unless you absolutely have to.
Make more of your tests Author-only tests
Decide which tests only makes sense for you, the author. Prime examples would be tests that check the documentation or running Perl::Critic. Others might be check if your network protocol handler conforms to the specification. Unless part of your code is specific to the system architecture, these tests only need to be run whenever you change the code.
Don't make assumptions about the users network architecture.
Quite a few dists in CPAN make assumption on how the network setup of a users should behave. Don't assume that the user is even allowed or able to access the internet. For the same reason, don't assume DNS resolution is going to get you the expected results, these days many users and companies run filters on Nameservers.
Don't try to access servers you don't personally own or have explicit permission to use
I've seen tests that run against other peoples (or companies) servers. This is generally frowned up on, you are wasting resources of the server owner and quite possibly their money.
Also, your tests might suddenly start to fail. You don't have control over those servers. If their configuration suddenly changes or they go offline, your users might have problems installing your dist.
Accessing certain sites may also be against company policy or even against the law in the country the user resides. Think "news sites" for example. Accessing news sites during work hours might get the user into trouble. Trying to access these sites might even get the user into legal trouble because they are "banned" in the users country.
Don't ask stupid questions while installing
Quite a few dists hold up the installation process to ask stupid questions. This is very annoying, especially if you run the installation on multiple hosts and once and you have to constantly switch through all tabs of your terminal. Just to check if some installation script has put its lazy feet on the table and won't do anything until you press enter.
Like "should i run the network tests over the internet". Answer: "No, you shouldn't" (see above). Provide some Author-tests instead that the user can run if they run into trouble - and document this in the dists "Troubleshooting" section.
Another good example is Template Toolkit. You get the questions "Do you want to build the XS Stash module?" and "Do you want to use the XS Stash by default?". How the f should i know? You are the author and you should know the answer to that better than me. If the author answer is "i don't know", then try to build the module while catching errors as non-fatal. If the module build, run its tests, if those tests work, use it as default.
Don't keep outdated tests and workarounds for external modules
If your dist uses external modules, and you encounter bugs, you will probably check for those bugs and write a workaround. Say the author of that module has since fixed the bug. Instead of keeping slow workarounds and extensive tests for that outdated module around, just require the current version of that external module as your minimum version.
Don't install if your requirements are not fulfilled.
If your dist needs either ACME::Foo or ACME::Foo::PurePerl installed to function properly, don't just print a message and continue. Either fail the installation (not good) or pick one at development time. In this case, picking the PurePerl version might be more reliable. Just printing a message during installation is pretty useless, especially if your dist is getting installed at the same time as a number of other dists. Your message might be on screen for only a fraction of a second.
Don't make the computer unusable during building and testing (unless you have to).
A good example where this is unavoidable is install Tk. It has to pop up many different windows to test this GUI library, which makes working on the computer while the installation is running impossible due to focus stealing. But if at all possible, avoid this.
Be careful when testing floating point numbers
Different systems might handle floating point numbers in slightly different way. Just because 1.0 + 0.05 = 1.05, this might not be true on the users system. It might only be "1.04999999". That is how floating point numbers work on on computers, because they use binary representations of varying length (precision) to work on those internally.
perl -e 'use Crypt::Digest::SHA256 qw[sha256_hex]; print substr(sha256_hex("the Answer To Life, The Universe And Everything"), 6, 2), "\n";'
David Plummer, a former MS software engineer with a popular youtube channel, recently posted a video comparing C#/C++/Python performance with a Primes implementation. He uploaded the source code to a github repo and people started adding implementations for many other languages. There's a Perl implementation, although I haven't yet looked whether it can be improved on. I thought I'd post it since I found it interesting and thought somebody might welcome the challenge of making a faster Perl solution (or making a Raku solution).
Today is six months since I created an account here in the Monastery...
Seldom have more than a few days passed without me kicking myself that I didn't do so much, much earlier. I have been writing Perl code since the mid-1990's but have learnt more in the last six months than in most of the time before. I managed to get quite a bit of 'stuff' working, mostly web based but also quite a few client tools. Even a handful of GUI tools using Tk. Over the years I has to do some C++ coding as part of my physics degree which I did not get on with and knew I never wanted to revisit... I've had a couple of brushes with Java including recently to create a couple of simple Android apps. But it has always been Perl that has been the language of choice.
When I needed to do something, I found out just enough to make it work. Then didn't go any further. Why would I? I didn't know there was a better way to do things!
A great example was when I posted some code and suddenly found out about placeholders in database queries...I had vaguely heard about the things but thought they were just for reusing one query multiple times. I soon found out they were a lot more useful than that. So useful in fact that all my code is slowly being converted. Re^5: Splitting the records into multiple worksheets
The Monastery changed all that from almost immediately entering. Straight away I was implored to use strict. Something I knew of but didn't understand. I thought it was a pain and made coding much slower. But I tried using it and, yes, I have to be more careful with my coding but that's no bad thing. Now all my code has use strict at the start. Just today I've refactored a script to include it and had to change 638 lines, mostly adding my to the start!
All my code now uses Template's where appropriate. All thanks to the Monastery. Yes, it was quite a learning curve but has enabled me to refactor an entire website and incorporate AB Testing right into the core. We just create test templates rather than having to duplicate all the code. So much easier to create, test and maintain. Certainly worth the learning curve.
My blind uncle now has automated curtains thanks to Controlling USB on Raspberry Pi which quite possibly would never have been successfully completed without the help of fellow Monks.
Plus, I have published a module on CPAN - Business::Stripe::WebCheckout
Something else that almost certainly would not have happened without the help and encouragement of so many Monks
Thanks for making the last 6 months sch a great period of learning....
Here's to plenty more time. Hopefully, over time I will be able to pass something on to new Monks.
I needed to save the cookies in HTTP::Cookies into Netscape format (aka 'cookies.txt'). Unfortunately I discovered that this functionality is offered by HTTP::Cookies::Netscape alone, which is a subclass of HTTP::Cookies overriding parent-class's load() and save() methods.
However, if one has no control over the creation of the cookie jar (that is, someone has created it and passed it on to us) then it's a bit of a puzzle on how to do that, easily. Actually I did not find a way apart from doing it manually myself by copy-pasting the contents of HTTP::Cookies::Netscape::save() into my own "static" sub which takes in a HTTP::Cookies and saves it in "Netscape" format. But that's a round-about way which also suffers from missing on any patches on the original code.
What I eventually did was to bless the original HTTP::Cookies object into a HTTP::Cookies::Netscape. Call the save() method, which is now different. And when that's done, bless-back to HTTP::Cookies. I just hope this method is as clean as it looks like without side-effects, provided that nobody touches the object in-between its many blessings.
Here is code demostrating the bless/re-bless:
use HTTP::Cookies;
use HTTP::Cookies::Netscape;
use LWP::UserAgent;
my $cookie_jar = HTTP::Cookies->new();
my $browser = LWP::UserAgent->new( );
$browser->cookie_jar( $cookie_jar );
# hit some pages
# now re-bless the cookie jar to obtain ::Netscape functionality
bless $cookie_jar => 'HTTP::Cookies::Netscape';
$cookie_jar->save("mycookies.txt");
# and now re-bless back to original
bless $cookie_jar => 'HTTP::Cookies';
Snippets of code should be wrapped in
<code> tags not<pre> tags. In fact, <pre>
tags should generally be avoided. If they must
be used, extreme care should be
taken to ensure that their contents do not
have long lines (<70 chars), in order to prevent
horizontal scrolling (and possible janitor
intervention).
