tl:dr; On 2nd of October I’m riding from Bristol to Birmingham to raise money for Birmingham Children’s Hospital. Please donate if you can.

In just under 2 weeks it’s my birthday. Apparently a bit of a landmark birthday. So I’ve been planning a bit of a challenge to celebrate. I’m aiming to ride the ~100 miles from Bristol to Birmingham (the planned route is 105 miles but I’m bound to take a wrong turn somewhere). I’m lucky to not want or need anything for my birthday so if you’re so inclined and have a few spare pounds then I’d welcome donations to Birmingham Children’s Hospital. Having 2 kids with long-term health issues gives us a deep appreciation for the people and facilities at the Children’s Hospital. Plans have been in flight for a while but today I went to visit Ozzy and sorted my train ticket and bike reservation taking me from Birmingham to Bristol on the morning of the 2nd October. I will then have the rest of the day to get myself back to Birmingham. For an elite rider, 100 miles is a bog standard training ride – it’s a surprising but true fact that I am not an elite rider so this is going to be tough. I’m not setting any particular time target other than hopefully arriving back before sunset (but I will be taking lights just in case!).

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.

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.

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 😉

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.

There’s a great list of Football pet peeves (via Smart Football – hands down my favourite football blog)

…..if I were ever named commissioner, the first rule I would enact is this: Any receiver who looks at a ref and does the little throw-the-flag wrist flip gets a 15-yard penalty and a lifetime ban from the league.

OK, I wouldn’t go so far as a lifetime ban but I whole heartedly agree (as with most of the other pet peeves).

One of my pet peeves which isn’t on the list is the idea of momentum, or in cliched coach speak ‘Old Mo’. Certainly a big play or a big hit can get a team fired up but I just don’t believe in a thing called Momentum, that one team has, and the other team doesn’t but can ‘take back’. Football history is littered with counter-examples but you only have to think back to the Superbowl to find the most recent.

In the 4th quarter the Cardinals had all kinds of Momentum on their side. They’d had a big goal line stand (2 if you consider that the stupid personal foul on Adrian Wilson gave the Steelers a fresh set of downs), and their D had all but shut down the Steelers O. The Cards offense had erased the Steeler’s lead and then put them ahead with only 2.35 (IIRC) left on the clock.

All the Cards defense had to do was do what they’d been doing all 4th quarter and shutdown the Steelers – they’ve got all the Momentum so it should be easy, right? Except ‘Old Mo’ didn’t turn up, and Ben Roethlisberger, Santonio Holmes and the rest of the Steeler’s O did – or did they somehow steal Momentum back? Did Holmes’ drop on the play before the game winning TD lose some Momentum? The whole thing is just nonsensical.

Football teams win / lose because they make / don’t make plays, and in close games it’s about making plays at critical times (just how Federer knows to conserve his deepest concentration for big plays). Smart Football doesn’t think much of Momentum either although Chris does a much better job debunking it than me.

On a sort of related note, NFL draft and free agency are upon us and I wonder what, if any, the affect of the struggling economy will have. I can’t think of a year where the no 1 draft pick didn’t sign for more than the previous years pick, and since the advent of the salary cap and free agency, and year that the cap didn’t go up, or that some free agent became the highest paid at his position. Sustainable growth or an about to burst bubble?

The NFL’s revenue sharing arrangements and salary cap should help buffer it from serious bubbles unlike the top Premiership teams which seem highly leveraged due to the skyrocketing transfer fees and wage demands, with no cap to limit them (last year Chelsea were £736m in debt). NFL teams could however suffer from cash flow or lack of credit problems as they have to pay signing and roster bonuses upfront (even though for salary cap purposes the numbers are pro-rated over the life of the contract). Likely the smaller market teams or those without mega rich owners who might be most effected.

But there’s not just pure economics involved. If the still wealthy are hiding their extravagant shopping behind unmarked bags (via Penelope Trunk) then I wonder if there will be a considerable backlash against ‘spoiled athletes’ holding out for a bigger signing bonus. I expect Drew Rosenhaus to be as unrepentantly money grabbing as always.

I also wonder whether the economic situation will spur on the restart of the NFLPA – NFL labour negotiations (once the NFLPA finds a replacement for the late Gene Upshaw). The thought of uncapped years doesn’t seem quite so appealing in a down economy.

Anyway it’s the offseason so I’ve got to have something football related to think about.

Don Marti wrote a rambling (for him) post about impact netbooks and linux, and musing about the great netbook windfall. Here’s some stuff I wanted to throw into the pot.

There’s still a lot of network value in a copy of Microsoft Windows because of all the compatible products out there. But, thanks to hard-working Linux driver writers, “driverless” USB class-compliant devices, and the rise of web-based applications to take the place of shrink-wrapped Win32 applications, the difference in network value is less and less at the low end of the market.

When ever you create a Linux based devices, whether it’s a phone, MID, netbook, laptop, there’s more to getting it consumer ready than trying out a LiveCD and knowing your ACPI tables. (I know that’s not what Don, or Harald, where implying – just trying a LiveCD would be a start for many). Even after the LiveCD runs there’s a not insignificant chunk of NRE that needs to be done to make sure that everything works together properly according to spec – in fact this is true of every hardware & OS combo.

So one of the hidden forms of Windows network value is that Acer, Asus, HP, IBM/Lenovo, Dell, etc have 10+ years of institutional understanding of what needs to be done to get hardware + Win{95,98,XP,Vista} ready, and (for some) 5+ years of server hardware + “Enterprise Linux” (but creating server room ready hardware and consumer ready devices is different kettle of fish). And now they’re learning, often the hard way, all the obvious stuff about building Linux consumer devices; while you can fork and customise and do your own thing you’re then left maintaining patches while projects move on, so it’s better to get stuff upstream; binary drivers are even more painful than on servers, fun with GTK+ and Qt theming, and yes ACPI tables, and on and on. There are more bonghits to come but hopefully less frequent and not as high.

OSV’s like Canonical, Xandros, Linpus, Novell etc can’t make the per device profit that Microsoft can but they can make a living (I would hope). Many of the netbook guys, Asus in particular, seem to feel that it’s a crime to let a few weeks go by without bringing out a new SKU, which is more NRE, and ongoing security and feature updates. So I would expect that being involved in desktop (or mobile) will be more than just a signaling strategy in the future – that increasing institutional understanding of how to get devices ready will mean that OEMs want to deal with OSVs that are directly involved in UI and Application projects, as to provide direct feedback and a greater likelihood of important changes & bug fixes going back upstream. That’s my theory, let’s see what happens.