The power of narrative in software development

I’m working on a piece of software that, while not the answer to world peace, is still pretty neat and approaches a specific problem in a fresh way. The project is at the stage where it needs to get unveiled to early adopters in the target audience. So how does one introduce possibly unfamiliar concepts in the form of a new API?

The approach we ended up using for the initial documentation is essentially a narrative–telling a story. Narrative fills the gap between use case and solution in an engaging way. People are naturally inclined to listen to stories, and to expect certain story structures, such as having a beginning, middle, and end with suitable transitions. Thus, if the listener senses a gap in the story, it’s easy for them to speak up. When the story works, people find it easier to map their personal story on to the narrative, leading to better absorption of new concepts, and a more positive impression of the software.

And it’s working. So far we’ve gotten far more useful feedback than we would have otherwise. Even before showing others, the exercise of writing the narrative has exposed gaps and flaws in our thinking, leading to a better, more cohesive design.

If you think back about how you learned about, say, object oriented programming, or event-driven programming, likely there was a story or detailed use case involved that helped you get on board with a new way of thinking. Software + story: It’s a powerful combination, I recommend it.

BTW, my team is hiring full-time positions. Especially if you’ve got XML skills, you could be part of this team. Send me email if interested. -m

2 Responses to “The power of narrative in software development”

  1. Kurt Cagle http://www.oreilly.com

    Micah,

    I’ve worked with narratives in software design before, and I agree with you it can prove to be a very powerful concept, because it forces you to mentally visualize activities, work flow and relevance. Features that may seem “cool” in a visual can, when exposed to a narrative analysis, fall flat or expose glaring weaknesses, while sometimes you end up realizing that there are things that you’d like to do but that the design as it exists doesn’t allow.

    The central challenge with narratives is very much the same as with any design process – the strength of such a narrative is directly proportional to the ability of the designer as story teller. Of course, if you can’t tell a story, then I think your abilities as a designer are likely very limited as well, because both require the ability to think about flow, pacing, economy of action and use of metaphor.

    I’d also invoke Scott McCloud here, as his books (especially Understanding Comics) should be required reading not only for the semiotician but the designer as narrator.

  2. Micahpedia : Micah Dubinko | Blog Archive | Software narratives: write better software by watching movies http://dubinko.info/blog/2008/10/13/software-narratives/

    […] more than others. Many of the concepts apply equally to software narratives. And like I wrote about earlier, such narratives are a powerful (if underused) tool in software development. […]

MicahLogic is Stephen Fry proof thanks to caching by WP Super Cache