Creativity and boredom aren't happy bedfellows. The eponymous narrator of Kiddar's Luck, a novel by the great but sadly forgotten Geordie writer, Jack Common, asserted that going to school had taught him one essential faculty, "with which every school infallibly endows its pupils, that of being bored. It is important, of course, that every child should in the course of time become fitted up with this negative capability. If they didn't have it, they would never put up with the jobs they are going to get, most of them, on leaving school. Boredom, or the ability to endure it, is the hub on which the whole universe of work turns."

We don't have to agree with every facet of this sentiment to recognise that too many employers deprive their employees of the ability to take the initiative and make creative decisions, and that the end result can often be a sullen or careless workforce that does just what it has to to make ends meet. Work doesn't have to be like this, and much could be learned, in software development environments at least, from the example of the open source development model, (if such a thing exists).

In the world of Free Software, anybody from any walk of life can contribute to the whole, and find a sense of acheivement as an equal partner, or even as a star, in a more convivial world where the measure of your worth is the quality of your contribution and the honest appraisal of your peers, rather than your ability to fit into the mould, or to climb the ladder of corporate respectability. At one extreme, Free Software projects abound with high-acheivers. At the other end, those who have made a mess of their academic careers, or have developed enthusiasms far removed from their working lives and academic opportunities, are able to dip into the code and make a difference in an atmosphere that is ultimately democratic.

The informality of the open source model, and its ability to allow participants to find their own level, encourages innovation beyond the reach of commercial structures. The critical factor is that all development is subject to peer review, enabled by collaborative software tools such as Subversion and CVS. Everybody has the right to contribute to the best of their ability, and make a difference. All too often in the world of work this right is sacrificed to the necessity of knowing your place, and keeping to the timetable. As Common observes: "The golden rule of the perpetually-bored is Punctuality."

Alice knows the tricks
Not so long ago, I lived in the East End of London and travelled fifty miles north to work, running against the tide of commuters pouring into the city every day. I caught a train from under the great Victorian arch of King's Cross station, and slipped into the "mobile free" quiet carriage, where at least ten fellow travellers would pick up their mobiles and shout "Hello, it's me. I'm on time!", after which they would pull off their jackets, take out their laptops, and play solitaire until the train reached the next station fifty miles up the line.

Being above this sort of thing, I would play Lieutenant Skat, a card game written by Martin Henni for KDE. Lieutenant Skat can be played as a multiplayer game over the network or as a single user game against the machine, which disguises itself as someone called Alice. Like any other game of cards fit to play on a train journey, Lieutenant Skat is addictive and annoyingly compulsive. As soon as you have finished one game you begin another, although you can't say why or what for. You are hooked. Unlike most other card games that can be played by a single user, Lieutenant Skat has a skill component of sorts, and Alice knows all the tricks...

A hack among hackers
I was a consultant software engineer at the time, a contract programmer, a hack among hackers, working for a company that was once part of a nationalised industry. This company had acted as newly privatised comapanies often do. As soon as the initial share issue was complete, the directors set about paring down the workforce.

Downsizing was the wisdom of the eighties and nineties, just as dumbing down has become the wisdom of the current decade. Downsizing was immediately effective - cutting the workforce trimmed the wage bills and increased share holdings and profits in the short term. The share holders loved it, for the first six months at least, and then discovered that all too often downsizing cut deep into the bones of the organisation, because the first people to go, low down the organisational tree, were often the ones who pulled the strings that made things tick. As anybody who has worked on a building site will tell you, the labourers who shovel the dirt often know the job better than the architects and surveyors who walk the site in suits and boots.

The project I was working on was a perfect illustration of this reality. We were replacing a huge high-tech piece of software that had been written in a matter of months by four employees in the seventies. This ancient but highly specialised software, written in Fortran IV, and ported at intervals to more modern hardware, had kept the organisation going, with a patch here and a patch there, for twenty five years. But those who knew the ins and outs of the software had been downsized...

So when the new realities set in, and new criteria for the software had been defined, the company resorted to hiring contractors, sometimes recruited from among the ex-employees who had been downsized, at exorbitant rates. There were sixty of us, managed by a team that had been parachuted in from a City consultancy, whose job it was to audit the project, and graduate project leaders freshly employed from Oxbridge colleges, who didn't have a clue.

Our incentive was that we were extremely well paid. Our disincentives were the audit trail, and a stack of wrong-headed software decisions that had been made at the management level. The main body of the software was written in Fortran on Alpha machines running VAX. Other parts were written in C on UNIX, and Visual Basic on Windows, a combination which doomed the project to premature obsolescence. Because we were freelancers, in receipt of fat pay cheques, there was little incentive to get to the end of the project, so we sat at our desks and played Lieutenant Skat, and watched the project revolve around us.

Being Svejk
But, our chief gripe was the audit trail. Everything went through the project librarian. Every change to the code required a form, and approval by a project leader. Every change required testing against a previous version of the code. No more than one routine could be changed at a time. Each change had to be checked by another coder, and signed off by the project leader. A change to a line of code would take a week or more to take effect. No rewrites could take place. The procedures were more important than the realities, and fixing errors in the code was often more trouble than it was worth.

I joined the project a year into its stately progress, and left nearly three years later, by which time the cost had risen by governmental proportions, and there was still no light at the end of the tunnel.
[img_assist|nid=89|title=|desc=|link=url,http://www.amazon.com/Good-Soldier-Svejk-Fortunes-Twentieth-Century/dp/0140182748/|align=right|width=114|height=150]

We had been chosen to work on the project because of our skills, but our skills were an irrelevance to the project. As a consequence, we were contributing work that was way below our collective abilities. We twiddled our thumbs, and played the fool, or sabotaged the project by not giving what we were able to give, being the Good Soldier Svejk and subverting the common purpose - not because of indifference, but because of enforced inertia, compounded by boredom, and driven by corporate addiction to a set methodology. No-one was encouraged to take the initiative, and say what everybody knew, that the project just wasn't working, and that any four or five of us could have rewritten the whole project from scratch in a fraction of the time, at a fraction of the cost, given a proper specification and a certain level of independence.

Boredom was the essential factor. As in so many work environments, our willingness to make a creative contribution to the success of the project was taken away from us by lack of trust and suppression of initiative. The boredom had set in. This stands in stark contrast to the progress of the more successful Free Software projects, where users and developers make huge contributions despite the lack of a financial incentive. Why should this be?

Parables and talents
Commercial and government organisations have a lot to learn from Free Software development models. Open source projects such as Linux and Apache have shown that software development is often more successful when developers and users are freed from the shackles of the formal process.

The "release early, release often" philosophy common to many Free Software projects has increased end-user involvement in the development process and enhances team communication. More importantly, open source development models encourage participation at all levels by all contributors. Your ability and your skill finds its own level, untrammelled by the interference of unknowing management. The mistake is to imagine that this process is entirely informal. It isn't.

CollabNet, for instance, which was founded by Brian Belhendorf, a co-founder of the Apache Software Foundation, is a company that has dedicated itself to translating the open source software development model into commercial software environments, with considerable success. The company's products, Sourcecast and Subversion, have been deployed in a wide range of Fortune 100 companies. Such tools, as commonly used by Free Software projects, allow for scalable collaborative development, and improve team communication. Archiving is automatic, and many of the documentation chores are eased by automated processes.

Forward looking management would also look at the way that those involved in open source projects find their level because they are able to contribute according to their interests and talents, rather than according to arbitrary selection, based on length of service or adherence to the rules. A recruitment policy that encourages involvement and responsibility will encourage greater loyalty and committment, engendering improvements in productivity. Such a policy would also allow employees to freely contribute to multiple projects, to encourage collaboration and creativity.

Alternatively, we can take a lesson from Kiddar, and assume that "most of us are unable to survive being educated. We learn reading and boredom, writing and boredom, arithmetic and boredom, and so on according to curriculum, till in the end it is quite certain you can put us to the most boring job there is and we'll endure it." But not me.
[img_assist|nid=90|title=|desc=|link=url,http://www.amazon.co.uk/Kiddars-Luck-Jack-Common/dp/1852241276|align=right|width=150|height=150]

Richard Hillesley