The Revealed Intention Exchange

Anant’s written a post about Orkut Crush which makes fascinating reading. Maybe it’s been happening across many social networking sites, and I just haven’t seen it; possibly because I haven’t used the “looking for someone” facilities.

Orkut Crush allows person A to register a  “crush” on person B, and vice versa; the registered information is only provided to the matched pair when both sides signal.

So at a level of abstraction it allows a signalling of intention, done in secret, with the intention only revealed to the other party when matching conditions are met.

There are many things that need matching. There are many ways of indicating interest or signalling intention.

I wonder.

Varieties of Work-Changing IT

I had the opportunity to spend some time with Andrew McAfee in London last week, but for some reason I hadn’t yet seen his article in November’s Harvard Business Review. So we didn’t talk about it. Shame, but one that’s easily corrected.
It’s well worth a read; I’m working on my comments and will share them with you in a post later. In the meantime, I believe it’s available free-to-air for the rest of this month, so do try and take a look, you can find the article here.

I just can’t resist one comment though. Take a look at the table below.

R0611J_A.gif

Andrew makes one very very important point. Not that the others aren’t important, but one of them really stands out for me.

In the table above, he defines Enterprise IT as “IT that specifies business processes“.

He does not say “IT that is specified by random and ever-changing and poorly articulated and inconsistent and sometimes even nonexistent business processes.”

IT that specifies business processes.

By this I don’t mean that the IT department has to specify all the business processes, that’s just plain stupid. What I mean is that enterprise systems work well only when there are rigorous standardised processes; they work well when these rigorous standardised processes are industrial strength, with external frames of reference; they work well when the number of processes is kept to an absolute minimum, and where process divergence and diversity is avoided. The “system” consists of people, processes and technology, working to common goals and held together by a common culture. Too often it’s the process piece that goes AWOL, aided and abetted by avaricious consultants, accepted and nourished by inertial inhouse staff.
IT that specifies business processes.

If only that were true. If only I had a dollar for every time “respectable” consultants plundered the heart of an organisation by mangling an enterprise resource planning system until it was as unfit for purpose as humanly possible. If only I had a dollar for every time “responsible” business users lapped up all this attention and “blamed” the internal IT department for rampant project failure, because they believed the lie. The lie that an ERP system was meant to mirror their existing processes. because they wanted to believe the lie. If only I had a dollar for every time the internal IT department quietly acquiesced and said it was all their fault, fired a few innocents, promoted a few bystanders, whatever. If only.

Of birds flying around unwalled gardens: There’s hope in them thar hills

For a while now, I’ve been tracking what’s happening with Songbird, and more recently I’ve started playing with it. It works. At least the parts of it that are meant to work, work.

cross_platform.png

Ross Karchner at Ross Notes puts it succinctly:

  • Songbird looks like it is shaping up to be the cross-platform, open-source iTunes replacement I’m looking for, with some really great integration with the larger music web– It’s like taking iTunes, ripping out the music store, and replacing it with the rest of the internet.
  • Browse to any web page with links to music, and it becomes a playlist. Songs play instantly, and saving them to your library becomes a single-click or drag-and-drop operation.

I love iPods, and will continue using them. Because they’re fantastic. In design and execution and usability and experience.

I’ve never bought anything from iTunes, though my children have. iTunes is nothing more than an elegant way for me to manage my music, music that I’ve paid for.

I love Macs. I still have fewer Macs than iPods, but the gap’s narrowing :-)

So why do I like what I see in Songbird? Because I don’t like lock-in. I want to be able to choose my device, choose my platform, choose my connection, choose my everything. I understand when that is technically impossible. I am less tolerant when it comes to creation of artificial scarcities and blocks. Just look at the garbage that is Region Coding on DVDs and you will see what I mean.

Songbird may not be the answer. We have to wait and see. But it has possibilities. And is “directionally” sound. [Pun intended].

On filmmaking and software development: Part 2

Yesterday I ended my post with a quotation from Wikipedia on development hell, and that’s where I want to start today. There are many reasons why film (and software) projects go wrong, and they all have to do with the script.

The script is central.

When producers and directors are looking to attract talent into a project, they use the script. When producers and directors are trying to get funding for a project, they use the script.

The script is central.

It represents an embodiment of the idea that sparked it all off, the problem that needs to be solved, the market with a barn-door sized gap, the customer itch that needs to be scratched, the business plan that’s looking for funding.

And unlike the past, unlike the waterfall and cascade days that led to their development hells with inflexible scripts, the script now evolves. We iterate through scripts. We cut the script down into bite-size chunks so that everyone understands what is needed, what is happening, what each individual’s role is. This iteration process helps us visualise what is happening, what needs to happen.

It is only when the script is stable that funding can be obtained. It is only when the script is stable that the project is initiated. It is only when the script is stable that we can speak about going “into production”.

Development is about scripts. Production is about making those scripts leap off the pages and becoming alive. Post-production is about making the experience available to all.

What are sets? Nothing more than reusable infrastructures with temporary skins. The key thing is that set designers really worked on making the sets reusable.

What about stock shots? Nothing more than reusable commoditised components that add limited value, yet remain necessary. So it’s important to spend as little time and money on them as possible.

The concept of calling a “wrap” is nothing more than really understanding modular design. You’ve compartmentalised something so that it’s got high cohesion and loose coupling, you’ve iterated through that piece until everyone is cool with it, then you’ve said “Enough”. Not Perfect. But Enough. You have time in post-production to fiddle with it, this is not the time. Move on.

More in the 3rd but not final part, which I hope to write sometime later today or tomorrow. It will summarise what I consider the lessons that parallel the two sectors, in tabular form. So why will it not be final?
Because Stephen Smoliar kindly pointed out that Tom Davenport wrote some parallel thoughts down in Information Ecology in 1997, particularly in a chapter headed “As shown on TV: A new model for information staff”. I promise to find a copy, read the chapter and try and tie it all together in a fourth and final post. Can’t say when, it depends on how long it takes for me to receive the book. I could cheat and use Search Inside, but I’m not like that. I’d rather fight to change the law.

And because I want to read the book now that I’ve peeked inside :-)

On filmmaking and software development: Part 1

For many years now, I’ve been intrigued by some of the more unusual similarities between filmmaking and software development; so much so that in 1997 I wrote a paper called Fast Iteration with Learnt Memory (or FILM), looking at how filmmaking techniques could be used in software development.

Things have moved on since then, both in filmmaking as well as in software development. If anything, the similarities betweern the two have become more pronounced over the years, catalysed and accentuated by agile techniques. So I thought I’d revisit the topic afresh.

Wikipedia defines five basic stages of filmmaking:

  • Development
  • Pre-production
  • Production
  • Post-production
  • Distribution

Here’s what Wikipedia has to say on the subject of development as a phase in filmmaking:

This is the stage where an idea is fleshed out into a viable script. The producer of the movie will find a story, which may be from books, other films, true stories, original ideas, etc. Once the theme, or underlying message, has been identified, a synopsis will be prepared. This is followed by a step outline, which breaks the story down into one-paragraph scenes, concentrating on the dramatic structure. Next, a treatment is prepared. This is a 25 to 30 page description of the story, its mood and characters, with little dialog and stage direction, often containing drawings to help visualize the key points.The screenplay is then written over a period of perhaps six months, and will be rewritten several times to improve the dramatization, clarity, structure, characters, dialog, and overall style. However, producers often skip the previous steps and develop submitted screenplays which are assessed through a process called script coverage. A film distributor should be contacted at an early stage to assess the likely market and hence financial success of the film. Hollywood distributors will adopt a hard-headed business approach and consider factors such as: the film genre, the target audience, the historical success of similar films, the actors who might appear in the film and the potential directors of the film. All these factors imply a certain attaction of the film to a possible audience and hence the number of “bums on seats” during the theatrical release. Films rarely make a profit from the theatrical release alone, therefore DVD sales and worldwide distribution rights need to be taken into account.

The movie pitch is then prepared and presented to potential film financiers. If the pitch is successful and the movie is given the “green light” then financial backing is offered, typically from a major film studio, film council or independent investors. A deal is negotiated and contracts are signed.

What does all this have to do with software?

Software is about stories.

As software becomes commoditised, what matters is the customer experience. And what the customer experiences is a story. As with films, stories are made up of scenes. Each scene has a one-paragraph description with clear directions to all participants in the scene.

Stories are about visualisation.

How does the customer experience the story? By visualising it. By seeing it unfold. By feeling part of it. The better the visualisation, the more engrossed the customer becomes. So it is with films, so it is with software. Customers respond to stories.

Visualisation improves with iteration.

That’s why the beta culture works. People know what they want and what they like when they see it. They also know what they don’t like, what doesn’t work for them, and they can point it out when they see it.

What gets iterated is the script for the story.

The centrepiece of a film is not the set. It’s not the special effects. It’s not even the actors, except insofar as they bring the story to life. It’s not the director either. It’s the script. That’s what makes the story. So it is with software. Get the script right and you will wow the customers.

Only successful scripts should get financed.

That’s what angels want first and foremost. Good scripts. Because they know that they can get good producers, good directors, good actors, good everything. But good scripts are harder to come by.
BTW, have you ever wondered why angel investors exist in only two investment genres, filmmaking and software development? Now you know.

There’s a lot more I will be covering in future posts over this weekend, including, in no particular order:

  • The central role of the script
  • The role of the producer
  • The role of the director
  • The cast
  • The set
  • Stars
  • Reuse and stock shots
  • Vendor independence
  • Iterating through scenes
  • Calling a “wrap”
  • Getting certified
  • Localisation
  • Subtitling
  • IPR and DRM issues
  • Revenue windows (e.g. from cinema to rental to purchase to free-to-air)

Let me leave you with a taster. Here’s the wikipedia definition of development hell as in the filmmaking context:

Development hell is media-industry jargon for a film, television screenplay or computer game (or sometimes just a concept or idea) getting stuck in development and never going into production.

In the case of a film or television screenplay, the screenwriter may have successfully sold a screenplay to a certain set of producers or studio executives, but then the executives in charge change, and these new people raise objections to all the scripts and casting decisions they oversee, mandating rewrites and recasting. As a director and actors become “attached” to the project, further rewrites and recasting may be done in order to accommodate the needs of the new talents involved in the project. Should the project fail to meet their needs, they might leave the project or simply refuse to complete it, causing further rewrites and recasting. Worse still is when a finished project (for example, a television pilot) is sent back for rewrites and recasting, which can often force a project to begin again from scratch. This process can last for months or years, and a project trapped in this state will more often than not be abandoned by all interested parties or cancelled outright. This process is not naturally an element of filmmaking. Many times, this “Hell” occurs simply due to the lack of foresight and competing visions of those parties involved. This revolving door in the film industry happens most commonly with projects that, to some, may have multiple interpretations and affect several points of view.

Sound familiar? And so to bed.