Many non-technical skills, qualities, and mindsets are part of software craftsmanship. Today I want to talk about two:

• Resilience
• Improvisation

Resilience helps us cope with difficulties by not giving up too soon. Improvisation deals with compromise and creativity in the face of the unexpected. The intuition to distinguish negotiable best practices from unchangeable truths is what agility is about. In earlier posts, I drew analogies between people from art and fiction (Stanley Kubrick, Woody Allen, and Gomer Goof).

Here’s the story of an agile musician I find very inspiring.

Murphy’s Law That Night in Cologne

Nobody could have dreamed he was about to record the biggest selling solo record in piano history, that night in Cologne on January 24th, 1975. Least of all Keith Jarrett himself. But when he took the stage in front of a packed opera house the five long improvisations flowing from his imagination were to make The Köln Concert a legendary album.

Yet Murphy’s Law had almost ruined everything. Jarrett arrived after an exhausting six-hour car ride from Zürich, sleep-deprived and with a crippling backache. Through some mix-up, the promised Bösendorfer concert grand wasn’t there, and the piano tuner was forced to make a rickety rehearsal instrument sound somewhat acceptable. With barely enough time to finish his meal, Jarrett was about to throw in the towel but he went ahead because a full house was waiting for him. You either love your work or you don’t.

Only Amateurs Need To Feel Like It

When there’s an important job to be done nobody cares if your heart is not in it. Parents know not to give in whenever their kids don’t ‘feel like doing something’. Only amateurs need to ‘feel like it’ before they can get started. I’m an amateur photographer, despite my fancy Nikon S-grade lenses. It’s not that I don’t stumble on the occasional great shot, but I just can’t be bothered to get up at 4 am for a two-hour drive only to shoot some spectacular sunrise. I don’t feel like it.

Stage actors don’t feel like it every night, and they don’t wait for inspiration either. Jarrett was exhausted, hungry, in pain, and probably still annoyed when he sat down behind the piano. But he started playing and suddenly neither organizational chaos nor his tired body could dampen his spirits.

As a creative profession, working in software means dealing with messiness. I never experienced an organization where every procedure was optimally devised and executed. I have never been in a team without dysfunctional behavior or attitudes from at least a few members. I have yet to see perfectly documented software without mistakes or ugly patches. I don’t write it myself. Every slick product only exudes perfection on the outside. Some improvisational duct tape is always there. Entropy is the norm, chaos never exceptional.

Truths and Best Practices

While resilience is about accepting what you can’t change, improvisation is about making the best of an imperfect situation that doesn’t fit the rule book. We’re always more than willing to give our fellow professionals well-meaning advice. We feel we must rein in their rampant creativity, but not so much our own. Human nature is full of these paradoxes. In movies, we root for the maverick detective who breaks all rules to catch the killer. Yet in the workplace, our gut response to messiness is calling for a bigger guidebook. Likewise in politics: we want a government that is firm with our neighbors but doesn’t nanny us.

Clean Code and other manuals like it give practical advice, but the overriding motivation for that is an understanding of the human condition and the nature of the work, expressed earlier in seminal texts like The Humble Programmer. Our mental capacity does not scale to keep up with the growing complexity of enterprise software. That is a hard rule of nature, so we devise best practices to avoid cognitive overwhelm.

The Limitation of Rule Books

If you’re not mindful of the motivation behind rules for clean coding and clear acceptance criteria, you’re just going through the motions. This explains the skepticism and even aversion against Scrum. The Scrum Guide is very proscriptive. It tells you thou shalt, not it depends. But its advice is not a description or explanation of how the human mind works when building software, even when it is inspired by years of experience in what works and what doesn’t. Read Felienne Hermans’ book The Programmer’s Brain for that.

In fact, it always depends. This is something the Agile 2 movement got right. A mechanistic application of human-made rules can never yield a successful team or product. Such rules have nothing to say about differences in experience, temperament, and hidden agendas. Accepting that the mechanisms which really rule this world are unwritten and vastly complex, can teach you more patience and flexibility.

The reality is that we’re building something complex and difficult with a diverse collection of people within an ecosystem of conflicting interests. Rules are not the only lubricant to keep the machine running. Going out for drinks after a stressful sprint can work wonders too.

Previously published on DZone