One of my favorite movies is “A River Runs Through It“, which tells a story of two brothers growing up in Montana. Their father, a preacher, conducts their schooling at home. In one scene, one of the boys is writing an essay, and each time he brings it to his father, his father tells him to do it again, and this time make it half as long.
I think of this quote often while trying to wrangle project descriptions into the miserly 140 characters that Twitter allows me. I want to tell each of you to rewrite your project summary, and this time make it half as long.
Here’s a few tips in shortening your project summary. (These are not absolute rules, of course – just suggestions you might consider in updating your project summary.) I’ve discussed this before, but I think it’s important enough to talk about again.
* Skip the “this project is an attempt to write software designed to …” bit. These are just extra words, and don’t convey anything about your software. Rather than saying that it’s designed to, or hopes to, or might some day, give me action words.
Before: “This project proposes to write software designed to edit audio recordings.”
After: “Edit audio recordings!”
Same meaning, but without the padding.
* Don’t tell me that it’s free and Open Source. This is SourceForge. Everything here is free, Open Source. It’s assumed. I always edit this part out when posting tweets.
Before: “This software is a free, Open Source podcast catcher.”
After: “Catch podcasts!”
Same meaning, but gets right to the point and doesn’t tell me something I already know.
* Skip words and phrases like “fast”, “easy to use”, “user-friendly”, “feature-rich”, and so on. You don’t have to tell me that your software is good. You have to tell me what it does, and then I can make that judgement on my own. Fast compared to what? Feature-rich? What features? Robust? As measured how? These things don’t add to my understanding of what your project does, and so just get in the way.
Before: This is a fast, robust, full-featured, user friendly birdsong identifier with a lovely blue user interface.
After: Identify birds by their songs!
Takes less time to get to the actual message, and tells me what I can do with it, rather than how happy I’ll be while doing it.
* I probably don’t care what language it’s written in. The “written in Java”, “written in PHP”, “written in objective C++” belongs in the detailed project description, not in the summary statement. I realize that this is a major selling point for some people, but it’s really not what your product *is*. I don’t care that my table was made with a Craftsman reciprocating saw, I care that it doesn’t collapse.
Before: Fast, robust full-featured wine database software, written in php with a mysql back-end.
After: Track your wine cellar on your website!
Tells me what it actually does. You can list your install requirements later.
As always, I’d be happy to advise you personally on how I would rewrite your project summary statement, if it were my project. Not that my answer is always the right one, but having read hundreds of project summaries, I know what catches my attention, and what makes me move on to the next project.