Tom had sent me some questions before the interview and I thought about answers for all of them, but we didn't have time to use them all in the time we had. So I wrote up the bits we didn't get to. If you've heard the podcast consider this an addendum to it.
Tom asked:
SPaMCAST listeners I have talked with are specially interested in understanding how you might recommend using stories for two scenarios. What are your thoughts on using stories: (a) to uncover requirements, and (b) to identify issues during a project retrospective?The requirements part of my reply is in the podcast. This is the second part, about project retrospectives.
Most people think source code is instructions for the computer. But that is only part of the picture. If instructions for the computer was the only thing that mattered, people would still be writing in machine language. Source code is at least as much about communication of intent from one person to another as it is about instructions to the computer. To some extent source code is a collection of stories about what people want to happen and what has happened along the way. So when people think about software development they should think about helping and allowing people to write stories as they write code. There is a lot of deep knowledge in "tribal memory" about why software is the way it is, and it often takes programmers new to a project a while to read the stories embedded in the code. The more people realize they are telling stories and do it on purpose the shorter and easier this can become.
Here is a quote from Grady Booch on the issue:
As the code written today becomes part of tomorrow's inexorably growing legacy, preserving these stories becomes increasingly important. It's costly to rely upon informal storytelling to preserve and communicate important decisions; it's incredibly costly to try to recreate those decisions and their rationale when the storytellers themselves are gone. Insofar as a software development organization can preserve its stories in a system's written architecture, it can make evolving that system materially easier.I would respond that it's only costly to rely on informal storytelling because we have poor tools to do so, and we could have better ones (and I'm working on better ones). With better tools informal storytelling could be a boon to software development.
When people work in complex areas where they have to solve problems and resolve dilemmas (such as in software development), they play out daily stories of tension followed by resolution. What I've noticed is that at certain predictable points in these stories, call them Eureka moments, people experience little bursts or pulses of energy for knowledge exchange. They want to tell someone what they discovered or fixed or decided. But in many work environments there is no way to capture those bursts of knowledge because no audience is available when the storyteller wants to speak, and the knowledge pulse dissipates and is lost. So an idea that would help improve KM in any group working in a complex knowledge environment would be to have a Eureka-moment system to capture knowledge-intensive stories before the urge to tell them dissipates.
I've noticed that when I am programming and experience such a Eureka moment, I often check in my code to the source code repository system. The system becomes my audience, and I tell stories to it. Sometimes later I go back and read the stories, especially when I'm returning to a project I had to leave for a time. I think programmers could be encouraged to do this more explicitly, and then the system could be improved to tell new team members the stories of the project. Imagine joining a team and having access not only to the source code but also to the Eureka (and "uh-oh") stories of its development so far. Some relatively small tweaks to repository systems could improve their ability to support storytelling in this way.
Also, there is no reason why source code repositories couldn't tell stories about the project as a whole to new group members coming in, or old members looking to learn from what has happened. Such systems collect huge amounts of information about what was changed and when and by whom, and with some thinking these could be formed into reports that tell the story of the project. This relates to the first point above, which is that if building software is as much a matter of communication as of engineering, systems that support it should support human communication as well as they support communication with computers. Telling stories about what has happened and why and what that means has always been a big part of human communication. This is especially true when people are working towards common goals together. I think more attention to this idea in software development would bring rewards to any project.
By the way, I mentioned on the podcast, and I'll mention it again, that Whitney Quesenbery's and Kevin Brooks' book Storytelling for User Experience is an excellent resource for the place where story and software design come together.
No comments:
Post a Comment