thoughts about software and sensible security.

Staging a play the agile way

S

It’s been roughly two years since I wrote and staged my IT-comedy Fair Trade, which we performed on location for two teams of developers. Great fun it was, and it’s available here if you read Dutch. With all my years of experience in incremental product delivery I was wondering: could you produce a play in monthly sprints, sharing the incremental deliveries with an audience? Spoiler: no, you couldn’t. It’d be torture for everyone involved. It’s waterfall or nothing.

A stage play is conceived much like an animal – humans included: you start with an idea and a plot, and flesh them out with dialogue and characters. You don’t start with the feet and proceed with the legs; it grows organically. Once you have a first draft you keep revising and rewriting until you’re confident that it will work on stage. You do a big, up-front design. Suppose you show all these intermediate draft versions to a live audience. No fun to sit through for either party, I can promise you that. It would be terribly cruel on the actors too: every month they’d have to learn all new words and rehearse different scenes. It’s also extremely wasteful: you’re basically throwing away all your source code to replace it with a better version each sprint.

Okay, then why not make sure scene one is perfect, show it to an audience and then proceed to scene two, right till the end? That way the audience experiences your story as it would view episodes in a series, and we append new stuff to the tried and tested parts we already have. This is actually how Charles Dickens wrote his novels: in monthly instalments. Sounds like a lot less waste, doesn’t it? But I wouldn’t like it any better. It takes time for an actor to get into the skin of their character and for that they need the whole story, not just the first scene. Dickens didn’t wing it, by the way. He prepared his stories and characters meticulously. Before the first deployment he had his backlog of stories sorted out, with very little refinement required.

As software people we may be tempted to think that an agile, incremental way of working is the best solution for any creative endeavour. But that’s not how it works. In fact, I’d rather think that software is the odd man out. First, it is functionally very complex. We don’t know exactly what it’s supposed to do down to the details and even then it will have to prove its usefulness in the field. By comparison, the use case of a bridge is not complex at all – even though the design and implementation will be. Secondly, software is reasonably malleable (if you code cleanly) and luckily we can adjust the destination on the way, because we so often have to. Unlike a railway or a bridge.

 

 

thoughts about software and sensible security.

Recent Posts

Jasper on twitter

Catching thought criminals in Orwell's analogue dictatorship was time-consuming and ineffective. A.I. will fix all… https://t.co/XpzIDondJe
h J R
I expect Mars to be successfully colonized long before we have flawless PDF to Word conversion.
h J R
Don’t tout #kotlin conciseness as a unique selling point. Concise does not equate understandable and if concise is… https://t.co/Hj7FrbZuI8
h J R
Hilfiger gives ‘smart dress’ a whole new meaning with new tracking chip. https://t.co/OeB4NEbVQI
h J R
ATDD is really different. Think of it as All Tests Drive Development. New blog post. https://t.co/J7uyHmCXFf
h J R