Staging a play the agile way

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.

 

 

Do we need a whole new “Ekosystem”?

There’s a joke that if you ask a developer to code a program to process widgets, they’d rather build a domain specific language and tool stack first to make life easier for when they might one day build the software that does the actual work.

A lot of development effort is under way to build a true Kotlin ecosystem, but I don’t think it’s all good news. Read more in my latest post for NLKUG.

Coding like Gaston Lagaffe

My favourite comic hero is Gaston Lagaffe by André Franquin. The series ran from 1957 till the early eighties and has been re-issued to the present day.

At the fictional offices of the Dupuis publishing house Gaston’s job was responsible to sort the incoming mail, but instead he wreaked havoc with his irresponsible fascination for the applied sciences. Everything Gaston touched resulted in a hefty bill from the real professionals and often a quick trip to the emergency room for him and his colleagues. Gaston was impulsive, reckless, without care or a shred of actual know-how, and occasionally brilliant. Granted, he was also an animal lover and never meant any harm. He was drawn most to mechanics and electronics, but also concocted a soap that ate through six floors like the blood of the Alien.
Continue reading “Coding like Gaston Lagaffe”

Anti-patterns part 2: Coding is the biggest Golden Hammer of all

In my previous post I explained how software anti-patterns are symptoms of bad habits that can be endemic to entire teams. Today I want to talk about what is perhaps the most infamous of all: the Golden Hammer. Actually, it’s a collection of hammers that makes up the toolbox from hell.

The Golden Hammer anti-pattern is a result of narrow focus, which in itself is an admirable and even necessary character trait for many pursuits: there’s a lot to admire in people who become experts in their chosen specialised field. It takes dedication and stamina. Science wouldn’t have made it to its present state without it. However, what makes a hammer golden is having experience and affinity with a technique (framework, language) that in itself has a limited range of applications but that you misapply through overuse. Continue reading “Anti-patterns part 2: Coding is the biggest Golden Hammer of all”