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.

 

 

Taking stock of 18 years in IT. What does it take to make great software?

This year my IT career is coming of age. In the year 2000, when URLs were still awkwardly pronounced double-you-double-you-double-you-dot, I quit an uneventful tech support job in Edinburgh to code in Perl and DHTML, cursing the incompatibilities between IE and Netscape. But I never regretted the career change. Eighteen years have passed and I’m happier and fitter then I was at age thirty, believe it or not. I thought it would be a fun experiment to rank all major projects and companies I worked with over the years in terms of overall satisfaction (without too much regard to pay or perks). You can make such a list intuitively, but I wanted to formulate the criteria which in my experience make a software project enjoyable and then give marks for each.

So I came up with the following four criteria, from most to least important.

Healthy team dynamics

There is nothing more important than a healthy team atmosphere if you want to build anything, and software is no exception. You need mutual acceptance of each other’s qualities without envy and respect for each other’s shortcomings without disdain. You must be able to assume that everybody in the team is sufficiently skilled and dedicated. Once these values are implicitly felt it is much easier to offer constructive criticism, preferably done with humour.
I have narrowed down the team to you daily work mates, including any non-tech people, management or possibly clients. There are of course more people to contend with:

Organisational support

Teams do not exist in a vacuum. There is upper management and corporate politics to deal with. There are client and other stakeholders, who can’t and shouldn’t be ignored, as they pay your wages. These are the ones you don’t see on a daily basis but still heavily impact the smooth running of the project.

How much do I care for what we’re making?

Don’t get me wrong: I always care about doing the best possible job, but I’d be lying if I claimed that all projects matter equally. Sometimes there’s a lot at stake. I have worked in projects where late delivery would have bankrupted the company, or a few hours of downtime would have cost many thousands in euros, not to mention embarrassment. Let’s call this the negative incentive to care, but you can also have a natural affinity with the industry or the end product which works as an extra incentive.

Code, architecture and tool stack

I deliberately put this last. While I’m a firm believer in clean code, testing and all the other good habits of healthy development, I have also come to the conclusion that people always matter more than tools. That’s why I find most programmer job adds uninformative and uninviting. “Join us and you can work with <INSERT FRAMEWORK>”. I want to know who I’ll be working with rather than what I’ll be working with. I care little for the rockstar attitude. No random group of rockstars is guaranteed to form a great band. Au contraire!

So without further ado, here’s my top fourteen, carefully anonymised. Note that the projects with the really cool tech don’t even make it into the top six. It wasn’t the tech that created the team atmosphere for me.

This little exercise has taught me that successful software development is way more than programming skills or tool knowledge. I’ll always prefer obsolete tech with great people over hacking Kotlin with jerks.
(Just kidding: there’s only cool people doing Kotlin)

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”

Kotlin’s invoke: it looks like a duck, quacks like a duck, but isn’t a duck

SUMMARY: Kotlin has given us a fresh perspective on some very ingrained OO-habits, particularly the pervasive use of nouns for objects that have only one public method.

Speaking like a native

Pronouncing a foreign language so convincingly that you can pass for a native speaker is one of the hardest tricks to pull off. While it comes natural to young children it is something that very few adults ever master. That is because our ears have become attuned to the speech habits of our native language and we interpret every foreign language according to these patterns. Continue reading “Kotlin’s invoke: it looks like a duck, quacks like a duck, but isn’t a duck”