Telling a story

I think everyone likes to hear a good story and I think a lot of people like to tell a good story. Sometimes
we're telling a story and sometimes we're telling a lot of stuff that happened. In the first case, we're performing. In the second, we're reporting. Even simply reporting what happened can be done in an interesting way. I am not a good story teller in the sense that I mostly just list the things that happened in order. Sometimes, there is an air of mystery to my reporting that draws people in but for the most part, I'm a pretty bad story teller. But like a lot of folks, I'd like to get to be a better storyteller. As I've said many times, I'm hoping that my writing in this blog will help with that. But you can't just keep making the same mistakes over and over again and expect to get better. You have to get some feedback from people reading what you've written and you have to learn new things from other people.

If you get a chance, take a look at the video that this link points to. It's a clip from the film The Last Tycoon. In this clip, Robert De Niro's character is trying to get a writer (played by Donald Pleasence) excited about writing for the movies. You can see Mr. Pleasence being drawn into the story Mr. De Niro is telling. That's what you want in a story. You can be telling people the most important thing in the world but if you bore them, they are not going to follow you.

Another interesting link is this one pointing to a list of 22 story guidelines written by a former employee of Pixar. These are not just useful for people wanting to tell animated movie stories. They are really good guidelines for any kind of story telling. And really, I think, most of them are really good guidelines for writing in general. As a matter of fact, I think a lot of these guidelines are really useful in writing software, too

In the the software development method we use in our office, Agile Development, we call the list of things we need to do to complete a project as the stories for that project. Yes, software development is a little like writing an article. For instance, a story might be:

I want to be able to find words in a document and mark them so that I can see them.

Yes, as a software developer, you write it up like it's something you (or a customer) would want to do. Then, under that story, you would list a number of tasks that must be done to realize that story. You have to split the story up into a list of definable operations that can be done in a reasonable time (usually less than a day). By making the tasks small enough, you aren't intimidated by them. For instance, the first task might be:

Get the text of document as a String

We're no longer writing it as a story. It's a task to do. You have to be able to get the text from your document in a form that the rest of your program can use. A String, in the Java programming language, is a list of characters, words and punctuation that you can access with the rest of your program. It's like saying that if you want to work on something, you have to be able to pick it up. Later tasks could be to use some sort of algorithm to look for specific words. Then another task could be to find a way to mark the words or phrases once you've found them. When you get to the last task, you've finished the story. When you finish all the stories, you've finished the project. And like item 8 in the Pixar list:

#8: Finish your story, let go even if it’s not perfect. In an ideal world you have both, but move on. Do better next time.

This is sometimes the hardest part of a software project - deciding when you are done. That's why it is very important in a software project to specifically write down what you plan to do. When you are finished with that list, you are done. There are always things you or the marketing department think about later that could be changed, improved or added to the project but that could go on forever. You have to release the product and then start working on the next version with the new and improved features. If you have a good product, you can keep improving it and making our customers happier. Only bad projects cannot be improved later. Or you keep adding features as you are developing it and it never gets released. That's a really bad project or a story that never ends. You'll start to see people leaving after a while.