Worth reading

Two very interesting articles appeared across the twitter feeds this week. First, via Chris Heilmann (@codepo8, who has too much awesome stuff to keep up), this amazingly detailed essay Learnable Programming

Alan Perlis wrote, “To understand a program, you must become both the machine and the program.” This view is a mistake, and it is this widespread and virulent mistake that keeps programming a difficult and obscure art. A person is not a machine, and should not be forced to think like one.

How do we get people to understand programming?

We change programming. We turn it into something that’s understandable by people.

Second, via Alex Russell (@slightlylate), is this thought provoking piece “The Moral Economy of Tech” by Maciej Ceglowski (@baconmeteor),

But as anyone who’s worked with tech people knows, this intellectual background can also lead to arrogance. People who excel at software design become convinced that they have a unique ability to understand any kind of system at all, from first principles, without prior training, thanks to their superior powers of analysis. Success in the artificially constructed world of software design promotes a dangerous confidence.


Microserfs was my favourite book of the late 90s and possibly in the top ten all time, but I’ve always been reluctant to go back a re-read again for fear that it wouldn’t stand up (unlike other Douglas Coupland books which I have read again). Well now I don’t have to as Alex Pappademas has nailed a look back at Microserfs mixed with review of Silicon Valley and Halt and Catch Fire (both of which I’m mid-season 1 with) – it’s like he wrote this exactly for me.

One reason why Microserfs is a strange read that feels epochs and not just decades old today is that its vision of Gates has been superseded in the culture at least twice…..Rather than an on-the-ground account of the first tech boom, then, Microserfs is an inadvertent time capsule of the moment just before the explosive growth of the consumer-facing Internet transformed society’s relationship to technology.

Ironically at the time I was working in something more like a McJob than “lost in a large corporation” job at fast growing company like Microsoft (quite apart from living in the West Midlands not Seattle / Silicon Valley). But despite the massive disparity in situations I still felt some kinship with the characters and their struggle to find themselves and meaningful work.

Lost Potential

Much of this software, in turn, has no proprietary value for the enterprises that develop it. So why isn’t the world deluged with enterprise-written open-source software? Why do so many CIOs gladly use open source but not contribute to it? Because open source is hard. Really, really hard.

So says Matt Asay in his Register column, and while I don’t disagree I also think it’s a lot like everything; the more you practice the easier it gets, and there are plenty of companies, large and small, that do push projects out as open source and over time they create a processes and policy to support that.

In fact the real problem is that Software is hard. Really, really hard – governance, code provenance, peer review, modularity, source code control, tracking bugs, responding to user/developer queries, etc are all things you want to do or issues you need to tackle in any well run software project regardless of the project being open or closed. Keeping a project in-house simply offers the possibility (the temptation?) to skimp or short cut on these things. Making a project open is a commitment to a wider community to do things right and be held accountable.

Aside: Kent Beck once commented at OSCON (in 2004 IIRC) that open source developers kind of have Maslov’s hierachy upside down, ie they start with self-actualisation (creating a project to scratch their itch), which can the lead to strong relationships with like minded people, respect from peers, and finally (if you’re lucky) a job to provide for food and shelter.

Matt links to Jim Whitehurst who laments “ Think how much software is written out there that is behind proprietary walls“. Again I like the sentiment but don’t regret the lost code or lack of economic efficiency as much lament the lost opportunity for personal satisfaction and growth, the missed opportunity to retain and nuture talented, creative people.

How many companies struggle with staff motivation and retention when experts from Dan Pink to Pete Carroll will tell you that the secret to happy and fulfilled employees is having autonomy and mastery over your work, to have a purpose in what you’re doing. Nothing beats this kind of retention policy or motivation, not even money (if fact simply giving people more money can, in fact, be de-motivating).

Maybe I’m just finding another scapegoat, but it seems that the real problem is not so much that doing open source is hard, or that lawyers get in the way, but that accounting for the benefits and costs of doing open source is too hard, so the value can be ‘proved’. Where the value is clear (or someone is willing to trust their gut) getting over the organisational hurdles will happen

“According to Whitehurst, JP Morgan’s CIO realized that support costs could be reduced by contributing the source code to the Linux community. Other Linux users would benefit, which would be nice… but more important to JP Morgan, the company wouldn’t have to invest its own resources in maintaining an internal application. The Merge code would now be updated and enhanced by Linux developers at large, in addition to any committers on its own staff.” From cio.com

This is presented as a pretty cut and dry case of not wasting resources (and therefore money) but actually the accounting is incomplete because various things are not factored in;

  • maintaining an internal fork is boring, fiddly, unrewarding work compared to working on the real Merge functionality – what of the affect on team morale, productivity, and retention
  • external usage can provide feedback and alternate deployment scenarios and testing which make Merge more robust (if you manage it correctly)
  • if your project becomes a standard open source component in it’s class, other parts of the stack will be written to integrate, interface, or compliment so ultimately your systems become easier and cheaper to develop

Suppose in the JP Morgan case making Merge open source actually required more, not less, resource – how do you factor in the above (and other negative factors) so you can calculate the break even point. Unfortunately I don’t know but I would wager that there is a strong correlation between teams efficiently delivering great products and/or services and management that creates opportunities for the their teams to grow and to build software the right way (which may or may not include making it open source – that’s actually a secondary detail).

Making the worker achieving implies consideration of the human being as an organism having peculiar physiological and psychological properties, abilities, and limitations, and a distinct mode of action. It implies consideration of the human resource as human beings and not as things, and as having—unlike any other resource—personality, citizenship, control over whether they work, how much and how well, and thus requiring responsibility, motivation, participation, satisfaction, incentives and rewards, leadership, status, and function. — Management by Peter F. Drucker [Kindle Edition]

I think this is the toughest challenge in any organisation – it’s a complex, inter-related, non-linear system, where the smallest, apparently insignificant, changes can have butterfly effects through the system, where small costs saving in one area can lead to huge deficit in others, where a small investment in something not “business critical” can indirectly reap huge dividends. Enlightened accountants are welcome to tell me how to do a cost benefit analysis of this upfront.

However I suspect it’s not possible otherwise we could just run everything through a spreadsheet and every company, charity, government dept, would just run like clockwork. Instead I’m reminded of possibly the greatest ever company about page of Ludicorp (the company that created Flickr) which quotes from “Disclosing New Worlds: Entrepreneurship, Democratic Action and the Cultivation of Solidarity by Charles Spinosa, Fernando Flores & Hubert Dreyfus (MIT Press 1997)” of which I will cut a snippet

One might think that they view their businesses as nothing more than machines to produce profits, since they do closely monitor their accounts to keep tabs on those profits.

But this way of thinking replaces the point of the machine’s activity with a diagnostic test of how well it is performing. Normally, one senses whether one is performing skillfully. A basketball player does not need to count baskets to know whether the team as a whole is in flow. Saying that the point of business is to produce profit is like saying that the whole point of playing basketball is to make as many baskets as possible. One could make many more baskets by having no opponent.

The game and styles of playing the game are what matter because they produce identities people care about.

Management is hard. Really, really hard. Man Up.


“Here we have a basketball mystery: a player is widely regarded inside the N.B.A. as, at best, a replaceable cog in a machine driven by superstars. And yet every team he has ever played on has acquired some magical ability to win.”

According to Michael Lewis, Shane Battier is the unmeasurable glue that makes the teams he plays on better (and knowing squat about basketball I’ll take his word for it – but I can think of many examples of such players in other sports). And so goes the dilema for anyone in management, whether sports, software development, or any other. There are certain teammates that defy statistical measurement, other than wins (in the case of sports teams), but that none-the-less these people indisputably make the team better (ie more likely to win, or create a great product, deliver a great service, etc).

In the end success, at least the elements the team can control, comes down to the individuals – each beautiful unique snowflake – what makes them tick, how they can contribute, how they work together as a group, etc. Unfortunately most large organisations that I’ve seen (both for- and non-profit) treat employees and/or volunteers as interchangeable cogs in a big machine, recruited against some cookie cutter arbitrary job spec, and measured every year against equally arbitrary and abstract performance criteria. Re-org’d, re-shuffled, and re-assigned at random intervals.

Most smart managers of high performing teams subvert, either directly or indirectly, consciously or subconsciously, the status quo and find smart people by any means possible, help them find them interesting and challenging things to do (unlocking the third drive), and build a structure for them to contribute, grow, and eventually leave. Smart companies treat people as individuals from the start – Zappos and Netflix come to mind, also Best Buy as a ROWE.

While there are always anomalies, teams ultimately dissipate over time – high retention rate could equally be a sign of stagnation rather than perfect team alignment and assignment. Your teams performance in 2+ years time will be defined by this year’s recruiting class – if you can keep them that long (aparently 20-somethings switch jobs every 18 months)

Who says management is boring?


“Kasparov can calculate more alternatives, whereas my intuition is better. I immediately know how to rate a situation and what plan is necessary. I am clearly superior to him in that respect.” – no shortage of confidence from the 19 year old worlds no 1 chess player. I only wish I could have been so sure of myself at 19.

You are entereing the QuietZone

One of the most curious concepts I encounter on a weekly basis is the concept of a ‘QuietZone’. For those who’ve not had the fortune to travel on one of the many (privitised) train operators in the UK the idea might seem obvious at first glance – a train full of people can be a noisy place – so why not designate one carriage, a kind of library like carriage, where the social contract is to keep noise to a minimum. Unfortunately, this being Britain, things are not so simple.


For the uninitiated this is a list of things that it appears is quite OK to do in the QuietZone (quite OK, meaning I have never seen another passenger complain about anyone doing these things – there is no formal definition, in the carriages at least, of what the QuietZone is/isn’t for other than the, somewhat defaced, signage above);

  • Talk loudly to the person or people sitting in adjoining seats
  • Eat noisy food (such as crisps, crunchy biscuits, etc).
  • Listen to mp3 players with headphones
  • Compulsively play with a noisy item, eg velcro fastening on a jacket
  • Generally make noise

However any of the following is almost guaranteed to inspire another passenger to remind you that this is a ‘QuiteZone’

  • Hold a mobile phone to your ear
  • Talk at any volume into your phone or headset
  • Do anything with a phone that involves noise – receiving an SMS, typing, etc.

Now I’m not making any judgement or outcry about this – I’m just reveling in the curiousness of the situation. Mobile phones users started out as a cultural outcast – loud, rude, inconsiderate (cf. the TriggerHappyTV sketch below) – and this got encoded in the expected behaviour of the QuietZone (whether intentionally or unintentionally), and has since got overtaken by what is now the cultural norm – that everyone has a mobile phone, and feels at liberty to use it without thought.

object width=”425″ height=”344″>

So you end up with the QuietZone, and the the myriad bizarre juxtapositions, like someone stopping mid (silent) Blackberry email to lean over to someone else talking (quietly) on the phone to remind them it’s the QuietZone, and using phones isn’t allowed.

And because of this, and because it’s such a British thing, whenever possible I book tickets in the QuietZone – it’s the funnest carriage in the train 😉

Jobs on the Moblin team

We’re looking for some smart people to join the Moblin team and help develop our little mobile Linux platform.

First up we have a position for a recent college graduate (Intel code for; you left University sometime in the last 18 months) to help us build the Moblin user experience. We looking for someone who has shown an ability to work productively within open source projects, and has a familiarity with common development tools such as C, C++, autotools, git, etc. For more details see the formal job description for Open Source Software Engineer – 569533

We also have two positions in a new team that will be building up our developer tools, documentations, SDK, etc. Here we’re looking for people with much more experience of open source projects (preferably experience as a maintainer, but not a hard requirement) and in depth knowledge of 2 or more of C, C++, or Java, plus the usual autools, git, svn, etc. Plus any experience creating developer tools or writing documentation will be a bonus. Again you can get more details from the job descriptions at Developer Tools Engineer – 568745 and Software Engineer – 568340

Any questions please feel free to ping me at pgc at the domain name of this blog (consider this the first initiative / turing test of the interview process 😉

Update: I should have made clear that all of these positions are based at our London office, and for now we’re not able to consider candidates working remotely, nor sadly do we have any relocation budget.