Making the usually implied disclaimer completely explicit on this one: the views expressed in this article are my own, and do not necessarily reflect the position of any organisations of which I am a member.
Power is an interesting thing, and something that, as a society at large (rather than the specialists that spend a lot of time thinking about it), we really don't spend enough time giving serious consideration to. Trust and fear, hope and despair, interwoven with the complex dynamics of interpersonal relationships.
The most obvious kind of power is based on fear: people listening when you tell them what to do, based on a fear of the consequences if they ignore you. Many corporations have traditionally operated on this model: do what you're told, or you'll be fired. "You might lose your job" then hangs as an implicit threat behind every interaction with your management chain, and a complex web of legal obligations and social safety nets has arisen (to a greater or lesser degree in different countries) to help manage the effectiveness of this threat and redress the power imbalance. Fear based power is also, ultimately, the kind of power embodied in the legal system.
That's not the only kind of power though, and this post is largely about another form of it: power based on trust.
Fear based power can be transferred fairly effectively: disobeying a delegate can be punished as severely as disobeying the original authority and so it goes. Interpersonal considerations don't get much consideration in such environments - they're about getting the job done, without any real concern for the feelings of the people doing it.
The efficiency of that kind of centralised control degrades fairly quickly though - with everyone being in constant fear of punishment, a whole lot of effort ends up being expended on figuring out what the orders are, communicating the orders, ensuring the orders have been followed, requesting new orders when the situation changes, recording exactly what was done to implement the orders and ensuring that if anything goes wrong it was the original orders that were to blame rather than the people following them and so on and so forth. It's like a human body that has no local reflexes, but instead has to think through the idea of removing its hand from a hotplate as an act of deliberate will.
There's a different kind of power though, summed up well in this YouTube video. What that kind of power is based on is the idea that once people have their core survival needs met, there are three key motivators that often work better than money: autonomy, mastery and purpose. (Note: this is after core survival needs are met. If people are still stressed about food, shelter, their health and their personal relationships, then autonomy, mastery and purpose can go take a hike)
At its best, an environment based on autonomy, mastery and purpose is one of mutual trust and respect. The purpose of the overall organisation and its individual components is sufficiently well articulated that everyone involved understands their responsibilities and how their efforts contribute to the greater whole, individuals are given a high degree of autonomy in determining how best to meet their obligations, and are supported in the pursuit of the required mastery to fulfil those obligations as well as possible.
This is the kind of distributed trust that Silicon Valley tries to sum up in its "move fast and break things" motto, but fails miserably in doing so. The reason? Those last two words there: "break things". It's an incredibly technocratic view of the world, and one that leaves out the most important element of any situation: the people.
This is a key point many technologists miss: ultimately, technology doesn't matter. It is not an end unto itself - it is only ever a means to an end, and that end will almost always be something related to people (we humans are an egocentric bunch). When you "break things" you hurt people, directly or indirectly. Now, maybe those things needed to be broken (and a lot of them do). Maybe those things were already hurting people, and the change just shifts (and hopefully lessens) the burden. But the specific phrasing in the Silicon Valley motto is one of cavalier irresponsibility, of freedom from consequences. "Don't think about the people that may be hurt by your actions - just move fast and break things, that's what we do here!".
This is NOT OK.
Yes, it needs to be OK to break things, whether deliberately or by mistake. Without that, "autonomy" becomes a myth, and we are left with stagnation. However, there's a difference between doing so carelessly, without accounting for the impact on those that may be harmed by the chosen course of action, and doing so while taking full responsibility for the harm your actions may have caused .
And with that, it's time to shift topics a bit. I assure you they're actually related, which may become clearer further down.
The glib answer here would be "a toxic cesspool of humanity", and I'll grant that's a fair description of a lot of them (see the earlier observations regarding fear based power). I am a capitalist though (albeit one that is strongly in favour of redistributive tax systems), so I see more potential for good in them than many other folks do.
So I'm going to give my perspective on the way some of the non-toxic ones work when running smoothly, at least in regards to three roles: the Chief Financial Officer, the Chief Technology Officer and the Chief Executive Officer. (You may choose not to believe me when I say non-toxic corporations are a real thing, but I assure you, such companies do exist, as most people don't actually like working for toxic cesspools of humanity. It's just that fully avoiding the descent into toxicity as organisations grow is, as yet, an unsolved problem in society. Radical transparency does seem to help a lot, though. Something about the cleansing power of sunlight and competing centres of power...).
The non-toxic CFO role is pretty straightforward: their job is to make sure that everyone gets paid, and the company not only survives, but thrives.
The non-toxic CTO role is also pretty straightforward: they're the ultimate authority on the technological foundations of an organisation. What's on the horizon that they need to be aware of? What's growing old and needs to be phased out in favour of something more recent? What just needs a bit of additional investment to bring it up to scratch?
The role of a CEO is a lot less clear. "Finance" is pretty clear, as is "Technology". But what does "Executive" mean? They're not just in charge of the executives - they're in charge of the whole company.
My take on it? The CEO is ultimately the "keeper of the company culture". They ultimately decide not only what gets done, but also how it gets done. While they have a lot of other important responsibilities, a key one in my mind is that it is the CEO's job to make sure that both the CFO and CTO remember to account for the people that will ultimately be tasked with handling "execution". They're the ones that say "no, we're not cutting that, it's important to the way we operate - we need to find another way to save money" (remember, we're only talking about the non-toxic corporations here).
So when employees of a corporation expect that company to do the right thing by them? They're trusting the CEO. Not the CFO. Not the CTO. The CEO. Arguably the key defining characteristic of a non-toxic corporation is that the CEO is worthy of that trust, as they will not only make those commitments to their employees, but also put the mechanisms in place to ensure the commitments are actually met. (This doesn't require any kind-hearted altruism on the CEO's part, by the way. You can get the same outcome through hard-nosed capitalism since making honest commitments to your staff and then keeping them is what "our people are our greatest asset" actually looks like in practice - it's just that a lot of organisations that say that don't actually mean it)
And that brings us to the specific reason I sat down to write this article: a tweet I posted earlier today regarding Mozilla's public debate over the board's choice of CEO. Specifically, I wrote:
I would take Eich accepting the Mozilla CEO role to mean his personal pride matters more to him than Mozilla's mission.
That's a pretty bold statement to make about someone I don't know and have never even met, and in relation to an organisation that I don't have any direct relationship with beyond being a user of their software and a fan of their mission.
Note the things I didn't suggest. I didn't suggest he resign from his existing position as CTO. I didn't suggest that the Mozilla board withdraw their offer of the CEO position. However, I did state that, from my perspective as an outsider that wants to see Mozilla execute on their mission to the best of their ability, "trust me" is a sufficiently big call to have to make for a role as critical as the CEO position that I don't believe Eich should be asking that of his fellow members of the Mozilla community. Actions have consequences, and one of those consequences can be "No, you no longer have the right to request our trust - you actively hurt us, and we don't believe you when you say you wish to make amends".
To Eich's credit, he at least didn't just say "trust me", but rather made a number of specific commitments. However, the time to build that credibility in a relatively open organisation is before accepting such a significant role, not after. Otherwise, there will always be a lingering doubt for affected individuals that any public statements are a matter of the responsibilities of the position, rather than a genuine change in personal convictions. When it comes to matters like a commitment to inclusiveness you don't want a CEO that is going through the motions out of a sense of obligation: this stuff is hard work and tempting to skimp on, even when you do care about it at a personal level (as a case in point - it would have been so much easier for me to not comment on this situation at all, that I almost left it at just a couple of vague allusions on Twitter rather than getting specific).
Separating the personal from the professional is always difficult, and few places moreso than the CEO role. During my tenure at Boeing, we had two CEOs asked to resign due to unprofessional conduct. The military industrial complex is a sordid mire of duplicitous misbehaviour and waste that makes the open source technology community look like saints by comparison (and I'll let you draw your own conclusions as to what it says about me personally that I survived there for more than a decade), yet even they were of the opinion that personal conduct matters at the CEO level, even moreso than in other less prominent roles.
For the record, I personally do hope Eich's newfound commitment to inclusiveness is genuine, and that the concerns raised regarding his appointment as CEO prove to be unfounded. I'd prefer to live in a world where the blog post linked above represents a genuine change of heart, rather than being merely a tactical consideration to appease particular groups.
Ultimately, though, my opinion on this topic doesn't matter - it's now up to Eich to demonstrate through his actions that he's worthy of the trust that the Mozilla board have placed in him, and for concerned members of the Mozilla community to decide whether they're willing to adopt a "wait and see" approach as suggested, or if they consider that belated request in and of itself to be an unacceptable breach of their trust.
Remember folks, the typical alternative to (A)GPL isn't a permissive license, it's proprietary source code and a proliferation of NDAs :P
— Nick Coghlan (@ncoghlan_dev) February 26, 2013
Inspired by Noufal Ibrahim's recent article on the general state of the Python community in India, I've finally written this belated report on my recent India trip :)
At the end of October, I had the good fortune to attend PyCon India 2012 in Bangalore. Sankarshan Mukhopadhyay (from Red Hat's Pune office) suggested I submit some talk proposals a few months earlier, and I was able to combine a trip to attend the conference with visits to the Red Hat offices in Bangalore and Pune. It's always good to finally get to associate IRC nicks and email addresses with people that you've actually met in person! While Sankarshan unfortunately wasn't able to make it to the conference himself, I did get to meet him when I visited Pune, and Kushal Das and Ramakrishna Reddy (also fellow Red Hatters) took great care of me while I was over there (including a weekend trip out from Pune to see the Ajanta and Ellora caves - well worth the visit, especially if you're from somewhere like Australia with no human-built structures more than a couple of hundred years old!)
While I wasn't one of the keynote speakers (David Mertz gave the Saturday keynote, and Jacob Kaplan-Moss gave an excellent "State of the Python Web" keynote on Sunday), I did give a couple of talks - one on the new features in the recent Python 3.3 release, along with a longer version of the Path Dependent Development talk that I had previously presented at PyCon AU in August. Both seemed to go over reasonably well, and people liked the way Ryan Kelly's "playitagainsam" and "playitagainsam-js" tools allowed me to embed some demonstration code directly in the HTML5 presentation for the Python 3.3 talk.
Aside from giving those two talks, this was a rather different conference for me, as I spent a lot more time in the hallway chatting with people than I have at other Python conferences. It was interesting to see quite a few folks making the assumption that because I'm a core developer, I must be an expert on all things Python, when I'm really a relative novice in many specific application areas. Fortunately, I was able to pass the many web technology related questions on to Jacob, so people were still able to get good answers to their questions, even when I couldn't supply them myself. I also got to hear about some interesting projects people are working on, such as an IVRS utility for mothers to call to find out about required and recommended vaccinations for their newborn children (I alluded to this previously in my post about my perspective on Python's future prospects).
One thing unfortunately missing from the PyCon India schedule was the target experience level for the talks, so I did end up going to a couple of talks that, while interesting and well presented introductions to the topic, didn't actually tell me anything I didn't already know. Avoiding any chance of that outcome is one of the reasons I really like attending "How we are using Python" style talks, and my favourite talk of the conference (aside from Jacob's keynote) was actually the one from Noufal Ibrahim and Anand Chitipothu on rewriting the Wayback Machine's archiving system (The other major reason I like attending such talks is that knowing I played a part, however small, in making these things possible is just plain cool).
While the volunteers involved put in a lot of effort and the conference was well attended and well worth attending, the A/V handling at the conference does still have room for improvement, as the videos linked above indicate. I've sent a few ideas to the organisers about reaching out to the PSF board for assistance and suggestions on that front. Hopefully they'll look into that a bit more for next year, as I think producing high quality talk recordings can act as excellent advertising for tech conferences in subsequent years, but doing that effectively requires a lot of preparation work both before and during the conference. There are some good resources for this now in the Python community at least in Australia and the US, so I'm hopeful that the PSF will be able to play a part in transferring that knowledge and experience to other parts of the world and we'll start seeing more and more Python conferences with recordings of a similar calibre to those from PyCon US and PyCon AU.
Since writing my Python 3 Q & A, including some thoughts on why the CPython GIL isn't likely to go away any time soon, I've been pondering the question of free-threaded cross platform virtual machines for dynamic languages. Specifically, I've been trying to think of any examples of such that are driven almost entirely by volunteer based development.
Prompted by a thread on python-ideas, I published some thoughts on understanding the behaviour of else clauses on Python's loop statements.
Apologies to RSS users, I still don't have a good setup for reproducing Sphinx content here on the blog - the real content is over on Read the Docs.
This interesting piece from Luke Plant went by on Planet Python this morning, and really helped me in understanding many of the complaints I see about Django's Class Based Views. That problem seems to be that when CBVs were introduced, they were brought in as a replacement for the earlier procedural Function Based Views, rather than as a lower level supplemental API that covered an additional set of use cases that weren't being adequately served by the previous approach (I only started using Django with 1.3, so it's taken me a while to come up to speed on this aspect of the framework's history).
The key point in Luke's article that I agree with is that deprecating FBVs in favour of CBVs and saying the latter is always the superior solution is a mistake. The part I disagree with is that saying this also means that introducing the CBV concept itself was a mistake. CBVs may have been oversold as the "one true way" to do Django views, but "There's one - and preferably only one - obvious way to do it" is not meant to apply at the level of programming paradigms. Yes, it's a design principle that's part of the Zen of Python, and it's a good philosophy to help reduce needless API complication, but when it comes to the complexities of real world programming, you need flexibility in your modelling tools, or you end up fighting the limitations of your tools instead of being able to clearly express your intent.
Procedural programming, functional programming, object-oriented programming, pipeline-based programming etc - they're all different ways to approach a problem space, and Python is deliberately designed to support all of them.
It helps to know a bit of programming history and the origins of OOP in the context of this discussion, as Django's FBVs are very similar to implementations of OOP in C and other languages with no native OOP support: you have an object (the HTTP request) and a whole lot of functions that accept that object as their first argument.
Thus, when you don't use CBVs at all, what you're really doing is bypassing Python's native OO support in favour of a truckload of what are effectively methods on request objects (just written in a procedural style). If you want to pass state around you either store it on the request, you store it in global state (which includes your cache and main datastore) or you pass it explicitly as function arguments (which means you have to daisy chain it to anyone else that needs it). If you use classes instead, then you get an additional mechanism that you can use to affect behaviour for a subset of your views. For example, I recently restricted write access to the PulpDist REST API to site admins, when it had previously been open to all logged in users. I could do that in one place and be confident it affected the entire API because every REST view in PulpDist inherits from a common base class. Since that base class now enforces the new access restrictions, the entire API obeys the rules even though I only changed one class.
Where Luke is absolutely right, though, is that switching from a procedural approach to an object-oriented one comes with a cost, mostly in the form of non-local effects and non-obvious flow control. If you look at Python's standard library, a rather common model to alleviate this problem is the idea of providing an implementation class, which you can choose to use directly, as well as a set of module level convenience functions. Much of the time, using the convenience functions is a better choice, since they're designed to be simple and clean solutions to common tasks. However, if you need to start tweaking, then being able to either instantiate or subclass the existing backend implementation directly lets you get a lot further before you have to resort to the brute force copy-paste-edit approach to code reuse.
But please, don't confuse "Django's Generic View implementation is overly complicated and FBVs should be retained as an officially blessed and supported convenience API" with "CBVs are a bad idea". Making the latter claim is really saying "OOP is a bad idea", which is not a supportable assertion (unless you want to argue with decades of CS and software engineering experience). While the weaker claim that "An OOP implementation is often best presented to the API user behind a procedural facade" is less exciting, it has the virtue of being more universally true. Procedural APIs often are simpler and generally introduce less coupling between components. The trick with exposing an OOP layer as well is that it increases the options for your users, as they can now: