I need to come up with a shorter title. Yesterday A few days ago, I gave some background on “Flow”, I know you guys are itching to get into some code; but remember we’re also attempting to talk about engineering software. Code is just one part of the engineering process.

I know there has been a lot of disdain lately for "”Big Process” or over documentation. But there are some documents that are worthwhile whatever methodology your subscribe to. One of those documents is the project vision and scope. Essentially, your project vision provides guidance for what the goals of the system are. As a rule of thumb, when considering a requirement ask “does this align with the project vision?”

I don’t believe much in process for process’ sake. I think Jeff Atwood said it best (in a post that I read as a result of my experiment), there is no recipe for the perfect program. Patterns, practices, and principles are not prescriptive, blindly following them is akin to trusting Google maps to get you to a destination in a strange town during construction season. In many cases, you’ll be just fine, but there will be those times when you wish you were more familiar with Milwaukee the town you’re driving through.

That being said, I feel that creating a project vision is an essential first step in starting a software project. The process (like making a business plan) makes you think, “Why am I doing this?” In many cases, a well-written vision will help you sell a project to management. In other cases, the vision serves as little more than than a daily reminder of what you’re trying to do. From a project management perspective the scope portion of the vision helps the PM decide if a feature is in or out for a project. Of course it can be adapted to fit whatever process you’re using. So if you’re doing agile or iterative development, you’d have a broad project vision and scope as well as a more narrowly focused iteration scope that says what’s in for a given iteration.

Up until now, my vision has been somewhat amorphous. The summary on the project page for “Flow” on codeplex is the closest I have to a project vision. Let’s rectify that situation.

First Draft

“Flow will be the most awesome software ever created. It will be able to read the user’s mind, anticipating what they want to do and respond accordingly. Flow will be so perfect that people will be willing to spend their life savings to acquire it.”

Although it would be great for “Flow” to possess these qualities, this doesn’t work very well as a product vision. Before we dissect it, we need to know what qualities make a product vision good. Fortunately, there is a lot of material available for someone learning about project management. Of course, one of my favorite starting points over the past few years has been Wikipedia. After a few steps of searching (which would be shareable within a completed version of “Flow”), I found the SMART acronym. Basically the product vision should be:

• Specific: state the vision in clear terms, making a precise definition of what’s expected from the final product
• Measurable: in other words it should be quantitative rather than qualitative.
• Achievable: you can set all the goals you want, but if their outside the realms of reality, they’re pretty useless
• Relevant: if you’re making a toaster, your customer won’t really care if it can be used to steam press their clothes (unless you’re selling one of those Swiss Army appliances you know what I mean)
• Timely: if you don’t put limits on delivery of your product, you’re likely to be lapped by the competition

I hope you can see why my original vision isn’t very SMART. Usually faulty goals within a vision aren’t that obvious. They’re more insidious like “…the best toaster on the market”. (Coincidentally, if you’re asked that question on an interview, they want you to question the definition of the best, not go about proving that it is.)

Once More With Feeling

Anyway, let’s try again to envision “Flow”.

“Flow” will be a desktop portal that provides a single point of entry to a users’ information while synchronizing it between their devices. Here are the desired traits of Flow:

• Extensible:  Flow will expose a plug-in architecture that enables extension of the application to include data from other information sources as well as different methods of visualizing that data.
• Social: Flow will allow users to share their data with their friends, family, co-workers, and the general public.
• Personal: Flow will allow users to take control of their information, enabling them to annotate, link, and tag it.
• Contextual: Everything we do with our computers has a context, Flow will help users preserve that context so that when they are distracted or need to switch contexts they can easily return to what they were doing.
• Discoverable: Flow will help users discover new features of the application and/or plug-ins for the application that will help them get more done. Think last.fm or Amazon recommends except for plug-ins.
• Accessible: Flow will provide a framework that makes it easier for information to be organized and presented for the impaired.

There we are, I think our vision meets the SMART guidelines, with the exception of Timely. We haven’t placed a time frame on the release of Flow. It’s somewhat difficult for me to time this. I have a day job and family. (Including a new child on the way.) My heart wants to have the first version available by June. Reality says it will most likely be a Beta in September and V1 at year’s end.

Of course all of that could change should more people volunteer to help (it is an open source project after all). Even then, there is a limit to how effectively the work can be distributed. We’ll see what happens though.