Some years before he died, as part of a collection of hitherto unpublished short stories called Bagombo Snuff Box, he wrote this:

“Now lend me your ears. Here is Creative Writing 101:

1. Use the time of a total stranger in such a way that he or she will not feel the time was wasted.
2. Give the reader at least one character he or she can root for.
3. Every character should want something, even if it is only a glass of water.
4. Every sentence must do one of two things—reveal character or advance the action.
5. Start as close to the end as possible.
6. Be a sadist. No matter how sweet and innocent your leading characters, make awful things happen to them—in order that the reader may see what they are made of.
7. Write to please just one person. If you open a window and make love to the world, so to speak, your story will get pneumonia.
8. Give your readers as much information as possible as soon as possible. To heck with suspense. Readers should have such complete understanding of what is going on, where and why, that they could finish the story themselves, should cockroaches eat the last few pages.”

When I read that, I could not help but think that we need a simple equivalent for software. Something along the lines of:

1. Use the time of a total stranger in such a way that he or she will not feel the time was wasted.
2. Give the user at least one function or facility he or she can root for.
3. Every function should satisfy some user need, however basic.
4. Every screen should do one of two things: reveal new functions or extend an existing function.
5. ………..

You get my drift. Don’t be put off by my paltry attempt, but I was thinking of setting up a wiki with the text and inviting readers to submit their entries and to vote for the best, just for the crack. What do you think? Let me know if I should.

My thanks to Steve Brodner of drawger.com for the drawing, I really think he captures something of Vonnegut’s attitude in it.

Unlike waterfalls (which run in one direction and don’t back up), spirals can produce software much more likely to match what users want. Spirals support usability, and usability drives the need for spiral development. But what comes after usability? And will new development approaches emerge to support it?

So, I guess I’m really asking two somewhat-related questions.

What are spirals? Kathy’s term for the family of techniques we know as Agile and XP and fast iteration, a term I happen to like. Here’s the context she uses it in:

Kathy puts forward the suggestion that what comes after usability is Flow, and, as you would expect, makes reference to the Godfather of Flow, Mihaly Csikszentmihalyi, and to his seminal book on the subject. By the way, she invites comment and opinion on her suggestion, so please join the fray at her site so that we can all learn from it.

While I was thinking about this, I was doing my usual thing and reading a number of other books and magazines in parallel. And one of the books I’ve been reading is quite unusual; it’s called Dreaming In Code, and it’s written by Scott Rosenborg, one of the co-founders of salon.com. When I saw it was touted as “the first true successor to Tracy Kidder’s The Soul of a New Machine“, the Data General person in me couldn’t resist picking it up. And seeing recommendations from Steven Johnson and Dan Gillmor made sure I read it. [An aside. As a result of buying the book I've discovered Scott's blog, Wordyard. Fascinating.]

In the book, Scott quotes from an interview he did with Joel Spolsky some time ago. While on the subject of methodologies, Joel is quoted as saying:

“The key problem with the methodologies is that, implemented by smart people, the kind of people who invent methodologies, they work. Implemented by shlubs who will not do anything more than following instructions they are given, they won’t work. Anyway, the majority of developers don’t read books about software development, they don’t read web sites about software development, they don’t even read Slashdot. So they’re never going to get this, no matter how much we keep writing about it.”

Incidentally, Scott makes reference to The Joel Test as part of this discussion, and it made me smile, just as it did when I first read it nearly seven years ago. If you haven’t seen it before, here are Joel’s Twelve Questions:

1. Do you use source control?
2. Can you make a build in one step?
3. Do you make daily builds?
4. Do you have a bug database?
5. Do you fix bugs before writing new code?
6. Do you have an up-to-date schedule?
7. Do you have a spec?
8. Do programmers have quiet working conditions?
9. Do you use the best tools money can buy?
10. Do you have testers?
11. Do new candidates write code during their interview?
12. Do you do hallway usability testing?

Anyone feel up to updating those 12 questions, to make them relevant to today’s context? [Yes, I do realise that the anti-Agile crew will probably insist that no such update is necessary... the same crew who claim that opensource is anti-innovation and anti-capitalist and anti-I-don't-know-what-else....]

Apologies for the ramble. What point am I trying to make?

Well, let’s start with Scott. One of the points he makes with real vehemence is the importance of constraints. I quote from his book:

Despite the odds — despite complexity and delay and unpredictable change — a lot of software does get written and delivered and, finally, used. Occasionally, it’s even good. Rarely, it actually does something new and valuable. And in a handful of cases, it achieves all of that on schedule.

Very often, in those rare cases, success is a by-product of iron-willed restraint — a choice firmly made and vociferously reasserted at every challenge to limit a project’s scope. Where you find software success stories, you invariably find people who are good at saying no. Like an artist who deliberately limits his pallet to one colour, a poet who chooses to write a sonnet instead of free verse, or a manufacturer who chooses to serve one small product niche, the successful programmer thrives because of, not in spite of, constraints.

if you’re interested in software development, you should read the book. Scott goes on to explain and develop the experience at 37 signals, an experience that really underlines the importance of user stories, in documenting what the user expects to see, touch, feel and do.

Then we move on to Kathy, who speaks about the need to move from usability and into flow, a state where the user is too busy enjoying what she is doing, too busy to critique or snipe at the software. Flow is when the user experience is no longer submerged in the software, but instead elevated to the outcomes that the software make possible.

Which brings me back full circle to a recent post of mine, where I was talking about Patricia Seybold’s new book, Outside Innovation. The excitement and the challenge of customer-created anything.
The excitement and challenge of helping make that happen.

Remember what Peter Drucker said all those years ago, something I’ve quoted before:

Shoes are real. Money is an end result.

Customers don’t want software, they want the things they can make and do because of the software.

When we speak of customer experience, it is not about the software, it is about the things they can make and do. That’s where the flow is, that’s where the joy and the magic are. I still remember the joy I had when I played my first Star Trek style game on a Commodore Pet, when I played my first text-driven adventure game on a Burroughs 6800, when I played my first game of Rats on a B20. Ah yes, nostalgia.

Whose joy? The customer’s. Who is in the Zone, who’s experiencing the flow? The customer. Who can define what that experience is? The customer.

Which is why everything we build should be built around user stories.

And that’s why I’m Confused. How come everyone doesn’t use Agile?

I used to understand how things worked, but lost my way after we discovered “productivity tools” and “end-user computing”. Ever since people started using spreadsheets and presentation tools, all the service industry rules changed for me. And I understood less and less.

Maybe I’m a dinosaur.

You see, I understood how individuals could use the spreadsheets and presentation tools, and I thought it was great. Then, when I saw some semblance of group work in these contexts, I thought I understood, and I hoped it would be great.

But the reality was different.

People spent incredible amounts of time producing the spreadsheets and presentations. People spent even more incredible amounts of time changing these things, arguing about what was in them, comparing the “content” with other sources of the same “content”. People spent time trying to acquire preview copies of spreadsheets and presentations; trying to influence what they contained; trying to differentiate what their particular thing said in comparison to what someone else’s thing said.

These productivity tools became the playthings of politicians. Particularly in large organisations. You know what I mean. It’s a bit like finding out that a GANTT chart was suddenly more important than the code deliverables it represented. [I know, I know, I've met those project managers as well....charlatans.]

The playgrounds that were called Meeting Minutes started looking deserted, as the serious players went on to bigger and better things. The power of presentation and graphics. And, particularly in Europe, the power of the spreadsheet. [Many years ago, I remember reading an unusual paper called Britain's Right and Left Handed Companies, written by a professor from Warwick. His first name was probably Peter, his surname was short, perhaps only four letters, I can't remember any more. But he looked deeply into this "figures" mentality and its European roots, and how it affected companies, particularly those in the UK]

Yes, I know I’m painting the lily. [Painting, not gilding. Gilding is what one does to refined gold]. But I digress.

Why am I so worked up about this, so much so that, explicitly, I didn’t allow for spreadsheets and slideware in Four Pillars?

Simple. Because these things are often lies. Without substance. They don’t need to be based on anything. Which makes the process of comparison and challenge and validation and verification truly painful. Yet everyone swears by them. Emperors and New Clothes. Everyone swears by them and everyone wastes incredible time using them. Unproductivity tools.

I think of spreadsheets and slideware in the same way I think of DRM. They pollute the path. Why do you think auditors the world over pore over and challenge ‘end user computing”, “desktop computing”, “spreadsheet computing” and their likes?

Which sane person would actually implement business processes that crystallised swivel-chairs all over the place? Let’s face it, that’s what we did. We didn’t learn from all the attempts at “Business Intelligence” and “Data Mining”. We didn’t learn from the prior pain of having implemented stand-alone non-referential systems. We went and enshrined all this in the way we work. No wonder ERP systems never delivered on their savings promises.

This is why I see no space for spreadsheets and presentation tools in Four Pillars.

There’s no point just ranting on about something, no point unless I suggest alternatives, new ways of working.

So I want to talk about broccoli.

Not really, except for the fractal bit. I think there’s something Small-Pieces-Loosely-Joined about the way we work today, something High-Cohesion-And-Loose-Coupling, that means that everyone deals with fairly well-formed items of work. Not piecemeal Assembly-Line, the way the productivity experts tried to make service industries work for the last fifty years. Somehow, we’ve gone and used concepts of workflow to break up tasks that cannot and should not be broken up, so that we felt happy in our assembly line cocoons and security blankets. Somehow we haven’t cared about the impact on our productivity, because we’ve had spreadsheets and presentations to hide behind. Standalone spreadsheets and presentations.

Now, with Web 2.0 tools and Web 2.0 ways of working, these things are changing. Tasks are becoming more fractal, and the information inputs and outputs are similarly fractal. Who knows, maybe we’re actually discovering what Object should have meant. I think that’s why I found what Sigurd Rinde was doing at Thingamy so fascinating. There was something about the way he looked at enterprise financial information that really jelled with me. He definitely saw through the clothes that weren’t there.

Which brings me to sand. Granularity. Granularity in the context of Four Pillars.

When I looked at the way Search, Publishing, Fulfilment and Conversation work, I realised more and more that there’s something different about the way we interact with information now. There are small pieces, for sure, but the pieces are beautifully formed and whole. Not sliced and diced to nothingness. Not summarised up the wazoo.

Now, when we see a summary of something, we can dig into what it represents. Dig and dig and dig until we go to the source. [In fact many years ago, not long after I started using spreadsheets, I met someone who had a startup in this space. I think it was called Forest and Trees. It may have become part of Symantec, I lost track. But they were on to something.]

Now, there’s no real loss of information as a result of synthesis and summary. No risk of error in multiple transformations. No need to reconcile stuff because you’re looking at the source anyway. No need to employ armies of reconcilers either. No need to spend years arguing about the figures on spreadsheets, or making the authorship of presentations something politically desirable.

Spreadsheets and presentations are like nuclear energy or e-mail. There are good uses and bad uses. The trouble is that for the last few decades, we’ve been in the Bad Use phase, and we need to break away from there. We need to make sure the small pieces stay loosely joined.

[My thanks to PDphoto.org for the wonderful royalty-free broccoli image. They do accept donations, though, which is good.]

doubling every
18-24 monthsIn the meantime, any of you who’s vaguely interested in the impact of opensource should take a look at it. I know it’s big and cumbersome, but you don’t have to print it. I know it’s detailed and tedious, but life is not always about soundbites. I know it’s full of figures and charts, some of them dating back to 2002, but a lot of it is largely new and interesting.

You can find the study via this link, which also takes you to the press release announcing the publication of the study earlier this week.

By the way, Rishab Aiyer Ghosh is one of the authors. I first came across Rishab when I started reading First Monday, and he quickly became a must-read for me. One of the books he edited, called CODE, or the Collaborative Ownership and the Digital Economy, is for sure one of my top ten business books of the decade. I think everyone who has even a modicum of interest in the DRM and IPR discussions should read the book, even before they read Lessig or Fisher.

Here’s a sample of the things I learnt in the skim

• There appears to be a Moore’s Law of sorts operating upon the FLOSS codebase, with a doubling every 18-24 months
• The FLOSS codebase today represents over 130,000 person-years of effort
• FLOSS-related services will represent 32% of all IT services within the next 3 years

Also, you may find these three diagrams of interest, showing the FLOSS committer population in the context of overall population, connected people and the rich. I’ve never seen this sort of information, so I think we owe the authors something.

One of the more intriguing observations in the study, which comes across in the summary as well as in the body of the document, is the following:

• That the current battles about DRM and IPR are having an undesired effect, and that is to deflect creatives resources towards “defensive” innovation.
• That FLOSS activities give us an opportunity to correct this blemish

Read it for yourself. Let me know what you think.

I used to track something called LiveSupport, which lately became CampCaster. If you get the chance, go there and take a look. Alternatively, I’ll save you some of the bother and quote some of the interesting bits from their site:

• Never heard of Campcaster? Here’s the elevator pitch: Campcaster helps you run your radio station. Do automated broadcasting and live studio playout in one system: schedule your broadcasts from the comfort of your own home with the Campcaster Web component, or do dynamic live shows with the Campcaster Studio desktop application.

  What’s the big deal about this release? We’ll cut to the chase: Campcaster 1.1 is the first release that is stable and feature-complete enough to be used in production systems. Indeed, the Campware implementation team will be helping to roll it out to multiple radio stations in Sierra Leone later this month. Other major radio stations are starting to adapt Campcaster to their needs: Austria’s Radio Orange is adapting the playout system to work with its digital archive, while in Hungary, a network of independent radio stations is integrating Campcaster’s storage server into its IKRA project, a generic public website engine for radio stations.

  “Awesome! Where can I get it?” you ask. The first thing you should know is that Campcaster only works on Linux. We recommend Ubuntu Dapper or any other Debian-based system.

  If you have an Ubuntu or Debian system, then just click here for installation instructions. Otherwise, click here to download.

This gets very interesting. In the lead-up to Y2K, despite everything the consultants did to raise FUD amongst the billpayers, many Eastern European and South Asian countries stood their ground. Houston, we don’t have a problem. Why? Because they computerised too late. The advantage of No Legacy.

When you look at the countries that are really making use of opensource, a similar pattern emerges. People who find lock-in a luxury too far. The infinitesimal cynic in me sees PL 480 equivalents where people are forced to use lock-in products and services, where governments set vendor locks in concrete. But then I remember 1974 and Daniel Patrick Moynihan writing what was then the world’s largest cheque ever, for $2.2 billion, and then presenting that cheque to Mrs Gandhi to clear the PL 480 residues.

Back to the point. See what the CampCaster site says:

The first thing you should know is that Campcaster only works on Linux. We recommend Ubuntu Dapper or any other Debian-based system.

If you have an Ubuntu or Debian system, then just click here for installation instructions. Otherwise, click here to download.

Is this the shape of things to come? Only Linux. With a recommended distro. But possible with other distros. Only Linux.

Linux is definitely becoming more and more mainstream, and we will see variations on this type of announcement all the time.

Take The Venice Project as an example. For years people have been telling me that there’s nothing they can use to watch TV on Linux, even though I showed them magazine articles that said they could, and even tried to show them the software. Tried. And failed. But that was in the past.

What now? What does the Venice Project say about this? I quote from their site:

• Does The Venice Projectâ„¢ work on the Mac or Linux?

• We’re working hard on a native Macintosh Intel version and expect it to be available in the next few months. Currently the application works fine under Bootcamp but not under Parallels; it needs to access the graphics processing unit (GPU) for some of its operations, and Parallels does not support that at the moment.
• A Linux version is also in the works.

Folks, we’re heading fast towards a world where Linux, OSX and Windows will coexist. Where the market will force people to make substitution-level interoperability something “normal” and to be expected. Where industrial-strength design coexists with elegance and coolth.

And I for one am looking forward to that new world.

A coda. You know, when IBM sold their PC division to Lenovo, I heard rumours that they did it because the management were sick and tired of the fights between their Linux guys and their Windows guys. I dismissed it as the fiction it was. But now I wonder.

Well, that’s what I did for a little while last month, struggling to get past the denial stage. I really didn’t know how to do nothing. Then, come the new year, I had a Road To Damascus experience and then I settled down into an easy rhythm of eat-read-sleep-potter-about-aimlessly, interspersed with the real joy of spending time with my wife and kids. While on the subject of convalescence, my thanks to all who sent me get-well-soon messages. As you can see the messages are working…

Now to the point of this post.

As part of the pottering-about-reading-aimlessly time, I came across this post by James McGovern, whose blog I get to reasonably often.

Read the post, it’s worth it. James commented on a perception held by some developers that many opensource communities aren’t particularly welcoming, and that developers are put off joining as a result.
And it made me wonder.

I’ve always believed in a community participation rule of thumb, something I’ve written about before here and here. The numbers tell the story:

• For every 1000 people who join a community:
• 920 are lurkers, passive observers
• 60 are watchers, active observers capable and willing to kibitz
• 15 are activists, actually doing something
• …and 5 are hyperactive, passionate about what they’re doing, almost to a point of obsession

And this is what I was musing about.

Does it really matter, the number of people who actively contribute to an opensource project? Is there something about the way opensource communities work, something that will always ensure that a very small number are the hyperactive core?

The more I think about it, the more I believe that there’s something important here. Linus’s Law is about eyeballs, not hands, and it’s for a reason:

• At the heart of every successful opensource community is a small cottage industry. And it is this cottage-industry mindset that makes the community different from other “commercial” ones.
• The core doesn’t have to scale. The core needs to behave in such a way that Linus’s eyeballs are attracted, and this is done by upholding the right values.
• Jerry Garcia and gang only needed to make sure that Grateful Dead concerts had “taping rows”; the number of people who sat in them was not relevant (although they were full). In a weird kind of way, the core is the band. The tapers are the activists. The kibitzers are the roadies and volunteers.
• Together with the audience, they formed a whole and vibrant community.
• Not everyone needs to be on stage for the community to work. In fact there isn’t space.

It is the freedom of access, represented by the taping rows, that really matters. That’s what makes opensource opensource.

Or, to take a chess analogy:

The threat is stronger than the move.