Numpy, culture

I came to see, in my time at IBM, that culture isn't just one aspect of the game - it is the game (Louis V Gerstner, "Who says elephants can't dance?" p182) 

I started a thread about governance on the numpy mailing list.  The thread didn't go very well.   It occurred to me that discussion on the numpy list has often been poor, and that this is due to the culture in numpy.

The problem as I see it is that numpy has a weak culture of participation.  There is a fairly explicit culture on the numpy list of listening to opinions not on the basis of the argument, but on the basis of the person's perceived or measured importance.  In fact, Scott Sinclair codified this in a semi-serious suggestion on the mailing list thread, where importance was to be measured by number of code commits.

I believe this is why discussions on the numpy mailing list are often unsatisfying and disorganized, with people talking past the point and offering opinions without addressing the issues.  This follows logically from the fact that opinions are assessed by the importance of the person delivering them.  Therefore, there is no need for the opinion to build on the argument that has been put forward, or advance from any point but the initial view of the author.   The discussion then becomes a series of impressions, and does nothing but point out that some people's impressions are different from others.  We listen to the impression of the person who is most important.

I have sometimes felt that this way of doing business is based on the idea that successful open-source communities are based on meritocracy.  I think this is a serious misunderstanding, and I try and justify that in my next post about meritocracy in open source.

Respect

Continuing a sport theme.

Today the England cricket team beat India by a huge margin, and so replaced India at the top of the world rankings.

Andrew Strauss has been captain of England since 2009.

The chief executive of the International Cricket Council, Haroon Lorgat [1]:

On behalf of the ICC, I would like to congratulate Andrew Strauss, Andy Flower and the whole team for becoming the number-one ranked Test team in the world. I know they were determined to be number-one and through careful planning and a series of clinical performances, they have deservedly achieved their goal. They were clearly the most consistent side in the world over the past few years as evidenced by their 19 out of 30 Test wins and only four loses. 

At the end of a long series of tributes [2], a comment by former England player and journalist Vic Marks:

Strauss has done a terrific job as captain, they respect him so much, he's got no ego at all.

[1] http://icc-cricket.yahoo.net/newsdetails.php?newsId=16661_1313236380
[2] http://news.bbc.co.uk/sport2/hi/cricket/14517827.stm

American capitalism and the common good

This is from the last few paragraphs of "The practice of management" (1958) by Peter Drucker.  He is writing from, and about the USA.

Two hundred and fifty years ago an English pamphleteer, de Mandeville, summed up the spirit of the new commercial age as "private vices become public benefits" - selfishness unwittingly and automatically turns unto the common good.   He may have been right; economists since Adam Smith have been arguing the point without reaching agreement. 

But whether he was right or wrong is irrelevant; no society can lastingly be built on such belief. [...] 

Fifty years ago de Mandeville's principle was as fully accepted here as it is in Europe.  But today it has become possible if not commonplace in this country to assert the opposite principle that the business enterprise must be so managed as to make the public good become the private good of the enterprise.  In this lies the real meaning of the "American Revolution" of the twentieth century.  That more and more of our management claim it to be their responsibility to realize this new principle in their daily actions is our best hope for the future of our country and society, and perhaps for the the future of Western society altogether.

Why you shouldn't use Google code

Google code is the only commonly-used open source hosting site that
uniformly blocks access from countries subject to US embargoes -
including Cuba, where I often work.  See the wikipedia hosting comparison.

You say 'oh well, they have to because they are in the US'.  Not so. They are not allowed to distribute code providing encryption, according to US law.   Sourceforge, when faced with the same problem, allowed projects to say they did not contain cryptography, and thus opt out of the blanket block.

Google's policy is contrary to the fundamental principles of open source - there should be "No Discrimination Against Persons or Groups".

But in Google code, there is discrimination.  Because if you're in Cuba, and you want to see a Google code web page, or any code, then Google will block you.

I don't know why Google has this policy.  Maybe someone thought it would be easier to block Cuba so they didn't have to worry about getting into trouble.  I suppose that person also assumed that you, dear reader, would not care too much about the loss of small liberties.

I hope you do.  I hope you don't use Google code, and that you encourage those who do, to change, and explain why.

I care about open source, and I care about my freedom to share work with others.  I care about this in practice, and I care about it in principle.  If you care too, please, don't use Google code.

Planning and doing

Planning and doing are separate parts of the same job; they are not separate jobs.  There is no work that can be performed effectively unless it contains elements of both.  One cannot plan exclusively all the time.  There must be at least a trace of doing in one's job.  Otherwise one dreams rather than performs.  One cannot, above all, do only; without a trace of planning his job, the worker does not have the control he needs even for the most mechanical and repetitive routine chore.  Advocating the divorce of the two is like demanding that swallowing food and digesting it be carried out in separate bodies.

Peter Drucker (1954) "The practice of management" Harper business edition, p284.

The Guardiola way

Y'all remember the del Bosque way?

Barcelona just won the football == soccer UEFA Champions League in the final against Manchester United.  It seems that everyone agrees that Barcelona is the best team in Europe, perhaps in a generation.

Barcelona's manager is Pep Guardiola, he's 40 years old, the youngest manager ever to win this title.

What is his management style?  In the interest of deliberate practice, we take a short pause to guess.  Then (Guardian article):  "impeccable, almost exaggerated politeness", "skills and simplicity", "intelligent", "flexible and resourceful", "he keeps going until he gets it right, no matter what he's doing".

Switch then to Barcelona, the club:

Eight of the team’s leading players are products of its football school, La Masia. That includes Mr Messi, an Argentine who moved to Barcelona as a boy, and the team’s coach, Josep (“Pep”) Guardiola. La Masia is unique among football schools. It is a boarding school that puts as much emphasis on character-training as on footballing skills. The students are relentlessly instructed in the importance of team spirit, self-sacrifice and perseverance. They are also taught that Barça is “more than a club”: it is the embodiment of Catalan pride that kept the region’s spirit alive during the years when Spain groaned under the fascist Franco regime. Fans regularly sport banners proclaiming that “Catalonia is not Spain”

Very simple lessons return from out of the noise; have a simple idea, be disciplined, build a team.  Beyond that, here and in other places, the organization and the leader are explicit about their purpose and their philosophy of work.

How to design and how to discuss

I really like this post by Linus Torvalds on the discussion about git and the default behavior of the git commit command:

http://article.gmane.org/gmane.comp.version-control.git/32843

I see these rich themes:

1. Get the concepts right, and understand them.  Proceed from the concepts and the rest of the design will fall out right. Then the argument for the default behavior of git commit is that the "[git commit] behaviour is absolutely REQUIRED once you get the whole "git tracks content" logic".
2. An argument that boils down to "I cannot imagine anyone doing that" is weak.  Linus calls this the "argument from incredulity".  Of course it disappears like mist in sunlight in the face of the counter-argument "The fact that you cannot see it doesn't change the fact that I use it all the time".

In a follow-up post, a classic:

I don't think people generally are all that stupid, and I think it's
actually counter-productive to try to basically lie about how things work.
It will just make it harder for people later.