The Software Engineer as a Novelist
July 21, 2022
In conversations with non-technical founders and leaders, I often come across the lament that the engineering department is an opaque box - requirements go in, working (sometimes not working) software comes out (but sometimes doesn't).
When imagining what's inside this box, many folk envision some kind of production assembly line - a conveyor belt transporting user stories, developers mechanically adding code as the story trundles past them.
With such a metaphor in mind it's understandable how confusing the unpredictability of engineering's output can be. This confusion is frequently quite frustrating - especially given how much of an organisation's scarce capital is involved.
Happily, I'm here to say that this metaphor could not be further from the truth.
Rather than an assembly line, I think things make more sense if you imagine that engineering teams are being asked to write a novel.
Immediately, you get a sense of the unknowns. Creativity, design, empathy are involved, and there's also plot coherency, narrative arc & language (architecture & software design) to consider - not to mention of course the dreaded "Writer's Block" (analysis paralysis).
To get this novel written faster, it's not uncommon to assign it to a team - or multiple teams.
Sometimes each team is assigned a chapter, and since they are working concurrently, the last chapter is written at the same time as the first.
Sometimes the front-end team is assigned the first sentence in each paragraph, the backend team is assigned the middle of the paragraph and the infrastructure team is assigned the last.
And sometimes the team assignment is as unwieldy as assigning each word in each sentence to different teams!
What to do about it?
There are a number of helpful approaches, but here are 3 ideas I've found incredibly useful:
The first is acceptance - that software is an inherently complex, creative, and unpredictable endeavour. Much like writing a novel, you don't always know how it's going to finish when you start, and it can take several drafts (iterations & refactors) before you're happy with the end result.
The second is to orient your engineers not around chapters, paragraphs, sentences and words (i.e. the technical elements), but around characters, themes and plots - in design parlance, your business domain: the concepts, stakeholders, processes and points of value.
The third is to exploit the ways in which software is NOT like writing a novel: it's hard to sell the first draft of a novel, but the first draft of a software system (an MVP) can still be valuable to a subset of your customers. Over time, you can expand the pool of prospective customers by incrementally enhancing your software.
The keys to this approach are:
- effective customer-value-focused prioritisation to ensure you're delivering real value early, and
- automated quality checks to ensure that as you expand the capabilities and support a broader customer base you can move quickly without breaking anything your early adopters are counting on
So next time you're asking a developer how long it will take them to complete a task, imagine you're asking a novelist how long it will take to finish a book - perhaps the conversation will take you in a different direction!
